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COMMUNICATION OF IMAGES OF ELECTRONIC 
FUNDS TRANSFER INSTRUMENTS 

Background 

5 The invention relates to communication of images 

of electronic funds transfer instruments. 

As seen in Fig. 1, payment of a financial 
instrument 10 is normally effected when a first banking 
institution 12 presents the instrument to a second 
10 banking institution 14. The second banking institution 
authenticates the instrument and transmits payment 16 to 
the first banking institution. Presentment of financial 
instruments among banking institutions may also involve 
intermediate steps, such as routing the instrument 

15 through a clearing house 18. 

When "the instrument is a written paper check 20, 
as in Fig. 2, a payer 22 presents the check to a payee 24 
during a transaction (such as a sale of goods or 
services) . The check indicates the name of the payee 26, 

20 an amount payable 28, a courtesy amount 29, the date 3 0 
the check was created, the printed name of the payer 32, 
the name of the payer's bank 34, the number of the 
payer's account 36 at the payer's bank, the payer's 
signature 38, check routing information 40, and a MICR 

25 line 3 9 which is a magnetic coding of some of this 

information. Essentially, the check directs the payer's 
bank to remove the indicated amount 28 from the payer's 
account and to pay that amount upon presentment of the 
check to the payer's bank. 

30 The payee places his signature 42 on the back of 

the check and deposits the check with the payee's bank 44 
with an instruction that payment be made to his account 
46. The check is then routed to the payer's bank 34 
through a clearing house 18, a federal reserve bank or 

35 other established clearing arrangement. This procedure 
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for effectuating payment between banks is known as 
forward check presentment. 

The payer's bank verifies the authenticity of the 
check and (at least for some checks) the signature 3 8 of 

5 the payer. If the check is authentic and the payer has 
sufficient funds in his account 36 to cover the amount of 
the check 28, the payer's bank debits the payer's account 
and transfers funds to the payee's bank in the amount 
designated on the check as payment 16. 

0 A check typically is considered authentic if it 

contains the signature 38 of the payer, the printed 
identification of the payer 32 and the printed name of 
the payer's bank 34, and does not appear to be altered. 
If the check looks authentic, the payee's bank 

5 provisionally credits the payee's account 46 for the 
amount designated on the face of the check 2 8 pending 
clearance, and acceptance and payment by the payer's 
bank. The payee's bank credits the payee's account when 
the payee's bank receives payment from the payer's bank. 

0 This procedure is known as check posting. 

A complete check transaction thus includes 
verification steps performed by the payer's and payee's 
banks 34 and 44. Processing a paper check requires time 
as the physical check is routed from the payer, to the 

5 payee, then to a clearing house, federal reserve bank or 
the payee's bank directly, and finally to the payer's 
bank. The same is true of other types of financial 
transactions involving paper instruments, such as credit 
card slips generated during a credit card sale. In a 

0 credit card transaction, a merchant makes an impression 
of the customer's card, which the customer then signs, to 
function as a receipt for the transaction. 

An important function of check processing relates 
to "exception" cases, such as a check returned due to 

5 insufficient funds in the payer's account. Since 
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exception processing provides for dealing with a problem 
in the normal flow of a check through the system, the 
physical check itself may need to be seen in order to 
resolve the problem. In this case, the paper check is 
5 routed back to the payee's bank or the bank of first 
deposit . 

Several mechanisms for using electronic 
communication to substitute for paper flow in financial 
transactions are in use or have been proposed. In 
10 particular, electronic presentment of checks is a 

mechanism used to aid in clearing checks collected by 
banks prior to or without routing the physical checks. 
Electronic Data Interchange (EDI) is an electronic 
transactional system in which funds are frequently 
15 transferred over existing financial networks. 

Check imaging is an electronic transaction 
procedure involving the scanning of a paper check by a 
scanner. The scanner digitizes the image of the check 
pixel by pixel and stores the image electronically in a 
2 0 memory. The image may then be transferred electronically 
to substitute for or precede the physical delivery of the 
check, i.e. to truncate the clearing process. The image 
of the check also may be recreated on a computer monitor 
or on paper for verification by the appropriate banking 
25 institution. 

Each bank may have its own system for capturing 
check images. A critical element of the interchange of 
check images is the ability to determine where and how an 
image can be obtained whenever it is needed. 
30 Summary 

In general, in one aspect, the invention features 
a computer-based method in which a first electronic 
representation of a financial instrument complying with a 
first protocol is created. The first electronic 
35 representation is converted to a digital delivery format 



WO 97/22060 PCT/US 96/2 0358 

- 4 - 

complying with a second protocol. The digital delivery 
format is delivered over an electronic data communication 
network. This enables information concerning the 
financial instrument to be delivered over the network in 
5 a pre-determined format. 

Implementations of the invention may also include 
one or more of the following features. The digital 
delivery format may be converted to a second electronic 
representation complying with a third protocol. The 

10 third protocol may be the same as the first protocol. 
The second electronic representation may also be 
processed. The processing may include displaying an 
image of the financial instrument or printing an image of 
the financial instrument. 

15 The first electronic representation may be created 

at a first financial institution and the digital delivery 
format delivered to a second financial institution, (In 
this application, whenever we use the words financial 
institution we mean them to include "merchants" . ) The 

2 0 second protocol may be a protocol recognized in common by 
the first financial institution and the second financial 
institution. The first protocol may also include a 
proprietary protocol of the first financial institution. 
The second protocol may include a commonly 

25 accepted protocol. 

The first electronic representation may include an 
image of the financial instrument or a digital codeline 
representation of the financial instrument. 

The financial instrument may be a check or a 

30 credit card slip. 

The first electronic representation may be stored 
for subsequent retrieval upon a request. The first 
electronic representation may be stored at a first 
financial institution. The request may be delivered 

35 electronically to the first financial institution from a 
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second financial institution and the digital delivery- 
format delivered to the second financial institution. 
The first electronic representation may be processed at 
the first financial institution. The processing may 
5 include displaying an image of the financial instrument 
or printing an image of the financial instrument. The 
request may be generated automatically. The first 
electronic representation may be assigned an 
identification index. The request may include the 
10 identification index. 

The digital delivery format may be encrypted for 
secure delivery over the electronic data communication 
network. 

In general, in another aspect, the invention 

15 features apparatus including a capture device for 
obtaining a first electronic representation of a 
financial instrument complying with a first protocol, a 
translator for converting the first electronic 
representation into a digital delivery format complying 

20 with a second protocol, and means for delivering the 
digital delivery format over an electronic data 
communicat ion network. 

Implementations of the instrument may include one 
or more of the following features. The first electronic 

25 representation may include an image of the financial 
instrument or a digital codeline representation of the 
financial instrument. The financial instrument may be a 
check or a credit card slip. The second protocol may be 
a commonly accepted protocol . The capture device may 

3 0 include a scanner. The translator may include an EDI 
translator . 

A memory may be included to store the first 
electronic representation. A workstation may be included 
for processing the stored first electronic 
35 representation. The processing may include displaying an 
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image of the financial instrument or printing an image of 
the financial instrument. The workstation may include an 
interactive display of the first electronic 
representation . 
5 In general, in another aspect, the invention 

features apparatus including means for electronically 
receiving a digital delivery format of a financial 
instrument complying with a first protocol, and a 
translator for converting the digital delivery format 
10 into an electronic representation complying with a second 
protocol . 

Implementations of the invention may include one 
or more of the following features. The electronic 
representation may include an image of the financial 

15 instrument or a digital codeline representation of the 
financial instrument. The financial instrument may be a 
check or a credit card slip. The first protocol may 
include a commonly accepted protocol . The translator may 
include an EDI translator. 

2 0 A workstation may be used to process the second 

electronic representation. The processing may include 
displaying an image of the financial instrument or 
printing an image of the financial instrument . The 
workstation may include an interactive display of the 

25 first electronic representation. 

In general, in another aspect, the invention 
features a method for truncating a paper check in a check 
clearance system by capturing an electronic image of the 
paper check at a first banking institution, the 

30 electronic image complying with a first protocol, 

converting the electronic image to a digital delivery 
format complying with a common second protocol, sending 
the digital delivery format digitally from the first 
banking institution to a second banking institution, at 

35 the second banking converting the digital delivery format 
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to an electronic image complying with a third protocol, 
and processing the electronic image complying with the 
third protocol for. clearance purposes. 

Implementations of the invention may include the 
5 following feature. The digital delivery format may 
include a secure format created by encryption. 

In general, in another aspect, the invention 
features a method for use by financial institutions with 
respect to financial instruments including storing, at 

10 different financial institutions, electronic images of 
paper financial instruments presented to the respective 
institutions, the storing at different financial 
institutions being done in accordance with different 
protocols, at each of the financial institutions, 

15 accepting electronic requests for copies of specified 
ones of the electronic images stored at the respective 
financial institutions, the requests being sent by any of 
the financial institutions via a common communication 
network, and at each of the financial institutions, 

20 responding to electronic requests by converting the 
requested electronic images to a common protocol and 
returning the images in digital form to the requesting 
financial institution. 

Implementations of the invention may include the 

25 following feature. The electronic requests may be 
generated automatically. 

The invention relates to the communication of 
binary content images of funds transfer instruments 
between banks. Each bank wraps the binary content in the 

30 bank's own proprietary format. A transmitting bank 
packages the proprietary format containing the binary 
content within a standard message format. The receiving 
bank uses the elements of the standard message format to 
find and interpret the binary content for use or display. 
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Advantages of the invention may include one or 
more of the following. 

Many business functions could benefit from check 
image interchange, including signature verification and 
5 stop payment orders and/or payer information. The 
interchange of images in addition to the electronic 
interchange of check codeline data allows truncation to 
be possible. 

The invention addresses the problem of check image 
10 interchange without physically exchanging paper checks. 
The invention provides an electronic communication 
alternative for check image transfer. 

The invention enhances the electronic presentment 
of checks with the addition of check images. Critical 
15 business flows are rearranged and altered. The invention 
also provides a new way to implement check processing to 
truncate the flow of paper checks. In addition, the 
invention provides a system for locating check images 
among the 15,000 banking institutions in the United 
2 0 States. Check images may be transported routinely or on 
demand . 

The invention provides integration of existing 
banking systems to facilitate check processing. The 
existence of these systems will allow for implementation 

25 and acceptance by the banking industry. 

The invention to a degree electronically mimics 
heavily-used and well -understood existing paper check 
processes to enable it to be readily accepted by the 
banking industry. By retaining the basic characteristics 

30 and flexibility of, e.g., the paper check, the invention 
may be adopted more rapidly. Due to the similarity with 
exchanging paper checks, the invention can be used within 
the structure of existing laws, regulations, and standard 
banking practices. 
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Since the system can be fully automated, and new 
processing can be done outside of existing applications, 
the cost of electronic check image interchange may be 
lower, and the costs of implementation minimized. To 

5 further minimize implementation costs, check image 

interchange may be integrated with the existing banking 
infrastructure, including some of the mechanisms 
currently used, such electronic presentation of checks. 

The use of electronic check image interchange will 

0 be more cost effective than existing paper checks due to 
volume efficiencies and the automatic processing 
capabilities of computers. The use of electronic 
transmission is less costly than physically transporting 
paper. Banks may significantly reduce the costs of 

5 mailing and/or transporting paper checks, such as for 
envelopes, stamps, and incremental labor. 

Other advantages and features of the invention 
will become apparent from the following description and 
from the claims. 

0 Description 

Figure 1 is a block diagram of a financial 
transaction . 

Figure 2 is a flow diagram of the steps of a check 
transaction . 

5 Figure 3 is a block diagram of a network of 

financial institutions . 

Figure 4 is a block diagram of a bank's check 
image interchange system. 

Figure 5 is a flow diagram of a check presentment 
0 application. 

Figure 6 is a flow diagram of a check query 
application . 

Figure 7 is a block diagram of a check image 
interchange system . 
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Figure 8 is block diagram of the functional groups 
of the ANSI X9.4 6 proposed standard. 

Figure 9 is a block diagram of a data structure 

scheme . 

5 As seen in Fig. 9, the invention provides an 

instrument image interchange facility 500. At one 
institution 498, a paper instrument 501- is scanned and 
stored using a conventional data structure 503 to capture 
the binary image content 504. Typical such structures 

1C include JPEG, CCITT Group IV, and IBM's ABIC. The 
instrument image interchange would require that the 
binary content of the image be kept in one of these 
formats or some other preapproved form. It also requires 
that the binary content be encapsulated (i.e., packaged 

15 or enveloped) in a preapproved common data structure 506, 
for example one complying with ANSI proposed standard 
X.9. If both of these requirements are met then the 
packaged data structure may be sent via any communication 
mode to any other institution which can then reliably 

2 0 recover and use the binary content of the instrument 
image by means of a readily available, easily defined 
algorithm. The data structure may also enclose 
information 510 from proprietary data structures 
associated with the binary content so long as it also 

2 5 includes the standard forms of data structure 
information. 

In current schemes it is common for an institution 
to envelope binary content in a proprietary envelope for 
various purposes, such as the IOCA scheme of IBM. The 

30 invention does not prevent continued use of such 

arrangements at each institution nor the inclusion of 
proprietary data structure information in what is sent 
between institutions, but it provides an alternative 
approach that permits fluid interchange of image content 

35 anywhere in the world via a wide variety of communication 



NSDOCID: <WO &722060A1 I > 



WO 97/22060 



PCT/US96/20358 



- 11 - 

media and among a wide variety of institutions for a wide 
variety of purposes without any two of the institutions 
having to engage in special negotiations to achieve the 
result. Each institution is able to rely on the common 
5 structures as assuring its ability to participate in the 
system. 

As shown in Fig. 3, banking institutions 5 0 may 
interchange check images via a network 52, such as a 
distributed TCP/IP based network. A TCP/IP network could 

10 utilize dial-up ISDN, for example. Electronic networks 
include the dial-up, Internet, wireless, and e-mail 
networks. Since security is critical for communication 
of electronic funds transfer instruments, established 
banking networks, which are secure and well disciplined, 

15 may be preferred to public networks. 

Each banking institution is a node on the network 
52 and has a server 54 (e.g., a UNIX server), a local 
image store 56 and a workstation 58 such as a personal 
computer with a monitor. Through the network, any one of 

20 these components in one bank may communicate with any 
other component in a bank connected to the network, 
whether or not the components are at the same location or 
geographically separated . 

In Fig. 4, bank 50 has an image capture system 62 

25 connected to its server. The bank which captures a check 
image is known as the bank of first image. The image 
capture system includes a scanner 64 for obtaining an 
electronic digital image of both sides of a check and for 
deriving codeline data from the check such as the payee, 

3 0 the payer, the payer's bank, the payer's bank account and 
the amount to be paid. The check may also include an 
imprint of a unique identifier for the check such as a 2D 
bar code which would allow tracking of the check by 
analyzing its image. The image capture system 62 may be 

35 a known proprietary system chosen by the bank, such as 
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the High Speed Image Item Processing System available 
from Unisys. The codeline data may be converted to an 
format for electronic presentment of checks by a 
processing system 66, which may be connected to the 
5 bank's server. 

The digital check image and the codeline data are 
stored in a data store 56 known as an archive. The bank 
may transmit both the codeline data from the check and 
the check image data over the same network, although the 

10 codeline data and the check image need not be transmitted 
together. The archive 56 stores the data in a 
proprietary format chosen by the bank, such as the Image 
Object Content Architecture (-IOCA) format of IBM or the 
Tag Image File format (TIFF) used by Unisys. 

15 Check image interchange involves a set of 

applications which provide user interfaces for banks to 
request check images from other remote banks, receive 
images from other remote banks, and provide images to 
other banks upon request . Two check image interchange 

20 applications concern forward check presentment and image 
queries. The applications manage the resources required 
to process the queries, responses and acknowledgements 
associated with check image interchange. 

The bank 50 has at least one workstation 58 for 

2 5 formulating and managing image queries to remote banks 

and for viewing retrieved check images by an operator. 
The bank may also support other applications 75, 
including its own use of the stored check images and 
codeline data such as for processing and viewing. 

3 0 In an alternative embodiment, check images and 

data may be captured and stored by a third party 
repository 57. The repository would provide an archive 
server 59 for access to the stored check images and data 
by other banking institutions. 
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The applications must support communication of 
check images and requests in a standard format since each 
bank employs its own chosen proprietary image capture and 
storage systems. The communications standard chosen for 
5 check image interchange is the ANSI X9.46 proposed 

standard. The mechanisms for routing check images and 
requests between banks and for searching for images 
utilize the X9.46 proposed standard for the entire 
interchange process. Although forward presentment of 

10 codeline data alone may be performed either with a 

commercially available product for electronic presentment 
of checks or using the X9.4 6 proposed standard, use of 
the X9.4 6 proposed standard will be assumed for present 
purposes. Details of the X9.46 proposed standard are set 

15 forth in the ANSI X9.46 Data Structure Reference, 

available from the X9B working group within ANSI and 
incorporated by reference. 

A system known as Image Locator Services (ILS) 72 
located in the bank as part of its server processes check 

2 0 image data, codeline data and query requests from the 
bank's proprietary format into the X9.4 6 proposed 
standard format for communication with other banks. A 
commercially available EDI translator 74 within the ILS 
may be used to perform the translation. The ILS 

2 5 determines where data is to be routed in the interbank 

exchange environment and provides the communications 
mechanisms needed to transmit information in the standard 
format. The check image interchange applications include 
information required to build the content of X9.46 query, 

3 0 image and acknowledgement messages and transmit them to 

and receive them from the EDI translator 74 via an 
application interface . 

As shown in Fig. 5, in forward check presentment 
100, check images and codeline data are captured (step 
35 102) using the bank's existing proprietary capture 
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equipment. The captured data is placed in an image 
archive in the bank's proprietary format (step 104). 

After capture, the codeline data from the checks 
must be packaged and sent to the payer's bank to initiate 
5 payment procedures. A codeline data file is created 

(step 106) which includes information for requesting the 
corresponding check images and the codeline data from 
which images to be viewed can be identified. For 
example, the codeline data file contains an image 

10 identifier corresponding to the stored check image. The 
codeline data is then sent to the ILS (step 108) . 

The ILS translates the codeline data file to the 
X9.46 proposed standard format and bundles it into an 
X9.46 data file (step 110). The translation process maps 

15 the file into an X9.46 data stream to send to the payer's 
bank. The codeline data may be sent by itself, or with 
the corresponding check image or portions of check image. 
Or, as described below, the check image data may be 
transmitted by itself. 

20 The ILS also determines the recipient of the 

translated codeline data (step 112) . Thus, the 
information sent to the ILS must contain enough 
information to identify the receiving institution. The 
ILS then determines the details for transmitting the 

25 translated file to the recipient bank, including the 

phone number to dial, the network address, and/or the e- 
mail address. 

The ILS executes the transmission to the recipient 
bank (step 114), and the recipient bank's ILS receives 

30 the transmission of the codeline data in the X9.46 
proposed standard format (step 116) . 

The recipient bank' s ILS determines the nature of 
the X9.46 data stream it has received (step 118) and 
identifies which internal system is to receive the 

35 codeline data. Knowing this information, the ILS 
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translates the codeline data into a format usable by the 
internal system of the recipient bank (step 120) . 

The ILS interfaces the translated codeline data 
file with the appropriate system for processing (steps 
5 122 and 124) . Although each bank may treat the codeline 
data differently, the codeline data ultimately is passed 
on to the appropriate internal posting system to complete 
payment of the check. However, at this time, not all 
banks post. checks with electronic presentment of checks. 

10 Thus, the result of the check presentment procedure is 

the identification of images that the recipient bank must 
request. Usually this is done to research problem items 
that cannot be posted directly from the codeline data for 
various reasons. Also, research may need to be done to 

15 handle other exception conditions such as stop payment 
orders, non-sufficient funds, closed accounts, etc. The 
result of the check posting procedure may be a report of 
check images to be examined or a list of items to be used 
in an automated query. 

2 0 In Fig. 6, in the check query application 13 0, two 

strategies may be employed to accomplish a query. For a 
single item real time query (step 132) , the operator 
enters the image identifier of the desired check image. 
The query for images to be viewed may also be 

25 formulated in advance and stored in a pick list to be 
batch processed (step 134) . For example, the exception 
processes may generate the pick list, or the operator may 
enter the image identifiers from a report. Received 
images may then be stored locally for off-line viewing. 

30 If the exception processes automatically generate the 
query, then the query can be carried out without any 
action by the operator, and the images would be ready for 
viewing when the operator is available. 

The processes generating the queries send the 

35 query request in the bank's proprietary format to the ILS 
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of the requesting bank (step 136) . The ILS translates 
the query request into an X9.4 6 data file (step 138) . 
The ILS also determines what system has sent the query 
request to determine which map to use for the 
5 translation. 

The ILS determines the recipient of the query 
request (step 140) . Thus, the information sent to the 
ILS must contain enough data to identify the institution 
to receive the request. The ILS determines the details 

10 for transmitting the request file to the bank that 

created the image, including the phone number to dial, 
the network address, and/or the e-mail address. The ILS 
then executes the actual transmission to the bank of 
first image (step 142) . 

15 When the bank of first image's ILS receives the 

transmitted query request (step 144), it determines the 
nature of the X9.46 data stream it has received (step 
14 6) and identifies which internal system (e.g., the 
archive) is to receive the query request data. The ILS 

2 0 translates the query request into a format usable by the 

archive of the bank of first image (step 148) . 

The bank of first image's ILS interfaces the 
translated query request with the archive to service the 
request (step 150) . The archive attempts to find the 
25 requested images and/or data (step 152). The archive 
sends the completed response (images, data, or error 
information) back to the ILS (step 154). 

The ILS of the bank of f irst image determines 
which internal system has sent the data to it to 

3 0 determine which map to use for the translation, and then 

translates the response into an X9.4 6 data file (step 
156) . 

The bank of first image's ILS determines the 
recipient of the query response (step 158) . Thus, the 
35 information sent to the ILS must contain enough data to 
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identify the requesting bank. The ILS then attends to 
the details for transmitting the file to the requesting 
bank, including the phone number to dial, the network 
address, and/or the e-mail address. The ILS executes the 
5 transmission of the X9.46 file to the requesting bank's 
ILS (step 160) . 

When the ILS of the requesting bank receives the 
transmitted query response (step 162) , it determines the 
nature of the X9.46 data stream it has received (step 

10 164) and identifies which internal system should receive 
the query response data. The ILS translates the query 
response into a format usable by the internal system 
(e.g., the workstation) (step 166). The workstation at 
the request, mg bank displays the received images (step 

15 168) , or the images and data received are stored for 
later inspection (step 170). 

Appi; cat ions for check image interchange have been 
developed by IBM and Unisys. The check image interchange 
components are provided on hardware and software 

20 platforms such as RISC/6000 for the IBM AIX system and 
U6CO0 for the Unisys UNIX system, as well as platforms 
for the EDI translator. Connection to the network may be 
accomplished through network boxes such as an Adtran 12 8 
DSU modem for ISDN connectivity and Cisco 2502 access 

25 routers for LAN connectivity to ISDN equipment. These 

have been used in pilot experiments. Any scheme that can 
establish a TCP/IP network may be used. 

The image capture system captures both the 
electronic digital images and the codeline data for 

30 checks. The scanners that may be used range from high 
speed reader/sorters such as those available from Unisys, 
AT&T and IBM, to low speed desktop scanners such as those 
available from Hewlett-Packard. In some systems, the 
codeline information is entered by the operator rather 

35 than through the scanning operation. 
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The image capture system exports the captured 
information to the archive and generates index 
information used for identification. The index 
information ideally includes the item sequence number, 
5 the cycle indicator {day of the week) , the processing 
data, and the initial storage device number. For 
convenience, export of information also should be 
controllable by other useful selection criteria such as 
sorter job. If the image capture system does not perform 
10 these functions, it must allow the archive system to 

access the information so that the data can be stored and 
indexed. Alternatively, the capture system may be 
integrated into the archive system for ease of storage 
and indexing . 

15 The number of views presented to the requesting 

bank for each .request corresponds to the number of views 
captured by the bank of first image's image capture 
system. Check image interchange may support varied image 
views, such as front black-white, front gray scale, back 

20 black-white and back gray scale. 

Storage and communication of check images is 
carried out in the compressed image format of the bank of 
first image. The image data compression algorithm used 
is determined by the binary image format of the bank of 

2 5 first image. Image data may be formatted using accepted 

compression algorithms, which include Adaptive Bilevel 
Image Compression (ABIC) by IBM , and CCITT Group 4 and 
the Joint Photographic Experts Group (JPEG) used by 
Unisys and AT&T. No image data conversion takes place 

3 0 prior to or during communications, and the receiving 

system converts the image as needed or desired. 

The use of electronic presentment of checks allows 
check data to be interchanged in real time and at volumes 
that current technology, price and performance can 
35 accommodate. By sending the data in codeline data format 



MSDOCID. <WO 9722060A1_I_> 



WO 97/22060 



PCTAJS96/20358 



- 19 - 

(which may also contain an identification label of the 
associated image) , the receiving bank can process the 
data, post the check, and be assured of resolving 
discrepancies with the data and handling exception 
5 conditions in a timely manner by accessing the check 
image from the bank of first image. In some cases, the 
actual check images will be forward presented, such as 
for items not qualified for processing of electronic 
presentment of checks or where the condition of the check 

10 would dictate a need by the recipient for the image. The 
receiving bank can resolve the problem causing the 
exception by viewing the image and making the necessary 
repairs to the data. 

The components of the ILS are constructed on a 

15 server, such as a UNIX-based server. The software 
components required to implement image capture and 
transfer through the ILS include the applications and the 
EDI translator. These software components enclose and 
optionally encrypt, perform hashing on, and provide a 

20 digital signature (if one does not already exist) for the 
compressed image in a ANSI X9.46 proposed standard 
envelope that identifies the image format and contains 
various pieces of data pertinent to the image, such as 
the index information. A digital signature may already 

25 exist prior to the processing; if so, the digital 

signature is simply passed through. The EDI translator 
maintains communication session control between the banks 
exchanging data in X9.4 6 proposed standard format. 

The EDI translator in the ILS constructs X9.46 

30 messages based on information received from the 

processing system, the archive and the workstation, and 
passes information received in X9.4 6 proposed standard 
format to these systems. Data is passed between the EDI 
translator and the other systems using an application 
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interface, which may include sockets, named pipes, Files, 
FTP, e-mail or other means. 

Image data, for example, is provided to the EDI 
translator in TIFF, IOCA or another image encapsulation 
5 data structure via the application interface. The EDI 
translator opens the image content and constructs the 
X9.46 interchange object based on the control data and 
the image binary data contained in the image object. 
Conversely, the EDI translator assembles image data 

10 received in an X9.46 data stream into TIFF or IOCA image 
objects as specified by the receiving bank's application. 

The archive provides a repository of check images 
and codeline data. The archive includes all the 
processing data elements necessary to locate images and 

15 codeline data from queries made to the system, including 
the item sequence number, processing date, cycle number, 
and device identification. Other financial data storage 
requirements may include the MICR line of the check, the 
bank of first deposit and document image number, the date 

20 the check was paid, and the disposition of the check. 
The images of the front and back of the check may be 
stored in their original capture format or in an export 
format that includes the data compression and an image 
wrapper . 

25 The archive interfaces with the ILS to perform the 

query function. The archive normally will be used both 
for check image interchange and for check processing such 
as normal proof of deposit operations. Alternatively, 
there may be a separate archive used solely for 

3 0 interchange or other functions. 

The archive system must be capable of receiving or 
importing images and data from the capture system. This 
exchange may be via seamless integration or a data export 
type of interface. The process of storing may occur in 

3 5 real time during capture, or in some cases it may be a 
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separate export process that takes place subsequent to 
capture. Further, some aspects of data integrity and 
security may be implemented within the archive system. 
The workstation provides a user interface for 
5 querying and displaying images. The workstation may 
support the entry of an image identifier for queries as 
well as imbedding the query functions into the various 
business applications that utilize check images, such as 
exception processing and signature verification. Upon 
10 entry of user data needed to formulate a query, the 
formatting routines of the workstation's software 
establish a query transaction to be transmitted to the 
ILS. Examples of workstation platforms are Windows and 
OS/2 Warp. 

15 The images returned to the workstation from the 

ILS after a query request are in the data format used by 
the bank of first image. No transcoding is done by the 
bank of first image. Thus, the display system of the 
workstation must be able to understand all of the 

2 0 accepted standard image formats. The workstation has 

software to decompress and decode received image formats, 
such as Image Viewer. 

Additional details of the check imaging system are 
shown in Fig. 7. 

25 As shown in Fig. 8, the ANSI X9.46 proposed 

standard 200 defines several functional groups for 
exchanging image information and coded data. 

The query request functional group 2 02 is used by 
the requesting bank to request one or more images from 

30 the bank of first image. Each query contains a unique 
query ID 204 for maintaining continuity between the 
original query, acknowledgment and the transmission of 
images to the requesting bank. 

The query request functional group 2 02 permits an 

35 image to be specified individually, based on its image 
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identifier,, or to be specified based upon generalized 
search criteria such as account number and serial number 
range. The requesting bank also may request check image 
formats that conform to its viewing software. Additional 
5 query request elements may include snippets of the check 
image, scaling and color. 

The items views functional group 2 06 is used to 
return image items requested by the requesting bank. 
This functional group supports transmission of one or 

10 more images. Item data loop structures 208 contain the 
information for imaged items. Multiple item data loops, 
each representing a single image, may exist within the 
functional group. Within each item data loop, one or 
more item view loops may exist to represent different 

15 views of the image. Therefore, a single transmission of 
an item views .functional group may contain multiple 
images, each of which may further contain multiple views. 
The views available to be sent to the requesting bank 
depend upon which views were captured by the bank of 

2 0 first image. 

The financial data functional group 210 is used to 
convey check codeline and other associated financial 
data . 

The application acknowledgment functional group 
25 212 provides a positive or negative application 

acknowledgment 214 that the content of the information 
received in an exchange is functionally correct and 
acceptable to the recipient. An application 
acknowledgment 214 may be requested in response to the 
30 transmission of a query request functional group 202, an 
item views functional group 2 06 or a financial data 
functional group 210. 

The functional acknowledgment functional group 216 
provides a positive or negative functional acknowledgment 

3 5 218 that the information received in an interchange is 
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syntactically correct for a functional group, transaction 
set, or data segment. A functional acknowledgment 218 
may be requested in response to the transmission of a 
query request functional group 202, an item views 
5 functional group 206 or a financial data functional group 
210. Unlike the other functional groups, the information 
in the functional acknowledgment functional group is 
supplied entirely by the EDI translator in response to 
the information received in the context of the functional 

10 group which invoked it; no input from the receiving 

application is required. The EDI translator constructs 
the functional acknowledgment functional group and 
transmits the response back to the requestor without the 
intervention of the application. 

15 The X9.4 6 proposed standard also supports other 

image capture and transfer functions. The query request 
functional group 2 02 and the item views functional group 
206 provide a security header which allows 
authentication, encryption services, and digital 

20 signatures to be applied to transmission of these groups. 
The X9.4 6 proposed standard also permits one or more 
transaction sets to be specified for each functional 
group. Additional functional groups and data elements 
may be added at a later date to support an expanded 

25 implementation of the X9.4 6 proposed standard. 

The EDI translator accepts source images in either 
the IOCA or TIFF object format, for example, and builds 
X9.46 interchange messages which are independent of the 
proprietary systems employed by the bank and which 

30 contain the appropriate control and data content, but do 
not rely upon the syntax of the original image data. The 
receiving bank may request that the translator 
reconstruct the image into its original object format, if 
it is known, or reconstruct the image object into a 

35 representation chosen by the bank. For example, the 
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sending bank may have provided the image as a TIFF object 
but the receiving bank may wish to reconstruct the image 
as an IOCA object . 

Under normal circumstances it is assumed that the 
5 receiving bank will select a single representation for 
all images it receives, and that the representation will 
be defined in the translator via a configuration table. 
It is also conceivable that the receiving bank may wish 
to dynamically define the format of the images it 
10 receives based on the source of the images. The format 
chosen by the bank will be incorporated into the EDI 
translator. 

The transaction is the basic unit of communication 
with the EDI translator. Each transaction contains the 

15 information necessary to represent the content of an 
X9.46 functional group. The EDI translator uses the 
content of the transaction to construct an X9.46 
functional group for outbound transmissions. For inbound 
transmissions, the EDI translator constructs a 

20 transaction from the received X9.46 functional group. 
The interface with the EDI translator includes pre- 
defined interface files. 

Each X9.46 functional group has a pair of 
dedicated interface files for outbound transactions to 

25 the EDI translator and inbound transactions from the EDI 
translator. For example, each interface file has a 
record length of BO bytes followed by a line feed 
character. Each record within a file represents a 
logical grouping of X9.46 data elements, referred to as 

30 segments. A segment consists of a segment identifier and 
the data elements, which may not exceed 8 0 bytes. The 
segment and data element structure of the outbound and 
inbound interface files is the same. 

A unique set of segments is defined for each EDI 

35 transaction type. These segments represent the mandatory 
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data elements required for each functional group in 
addition to any optional or conditional elements 
necessary for implementation of the applications. New 
segment definitions may be added to incorporate 
5 additional data elements. All interface file segments 
records must be built by the application in the sequence 
specified for a particular transaction type. 

Data elements within a segment have fixed lengths, 
with no delimiters between data elements. Binary data 

10 elements are contained in a separate file whose name is 
contained in a segment data element. The order in which 
data elements appear in the segment may not necessarily 
correspond to the order in which they appear in the X9.4 6 
functional group. All segment data element positions are 

15 present in both outbound and inbound transactions. 

Except where noted, all data elements contain data in 
both outbound and inbound transactions. In those cases 
where the length of a data element may be less than the 
fixed length of the data element field, the data is left- 

20 aligned and the unused bytes must be padded with ASCII 
blanks . 

An X9.4 6 loop structure may be represented by a 
single segment or a sequence of segments. Loop 
iterations are specified by repeating the segment or 

25 segments for the required number of iterations. The 

nesting sequence of outer and inner loops is as described 
in the ANSI X9.46 proposed standard specification. Loop 
structures must be constructed in the order described for 
the transaction type. Subordinate loop sequences must be 

3 0 completed before the next higher level loop can be 
repeated . 

A transaction set reference ID 220 is used to 
associate two functional groups. For example, the 
transaction set reference ID is used to associate the 
35 item views transaction to the query request transaction 
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which requested the images. The transaction set 
reference ID of the query request will be inserted in the 
transaction set reference ID of the resulting item views 
transaction to allow the receiving application to 
5 associate the inbound item views transaction with the 
query request transaction that requested the images. 
Since the EDI translator generates the transaction set 
reference ID for all outbound transactions, the 
transaction set reference ID must be returned to the 

10 application in a status file after the EDI translator 
builds the outbound transaction. 

In a transaction, the application sends an 
outbound query to the EDI translator. After building the 
query request transaction, the EDI translator returns the 

15 transaction set reference ID 220 to the application in a 
status file. The receiving EDI translator passes the 
transaction set reference ID of the query request 
transaction to the receiving application along with the 
query contents. When the receiving application builds 

20 the item views transaction, it passes the transaction set 
reference ID of the query request transaction to the EDI 
translator, which inserts it into the transaction set 
cross reference ID of the item views transaction. This 
associates the item views transaction with the query 

25 request transaction. When it receives the item views 
transaction, the application which sent the query 
extracts the transaction set cross reference ID to 
associate the inbound item views transaction with the 
original query request transaction. 

30 The EDI translator maintains two status files 

which will be available to the application after every 
outbound call to the EDI translator, one for results of 
outbound query requests and the other for results of 
outbound item view requests. The status files contain 
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the call status and the transaction set reference ID of 
the transactions created by the EDI translator. 

The EDI translator builds a status file with the 
appropriate file name after processing an outbound 
5 request from the application. The status file is 
available to the application after a return code is 
posted for the call. Once the status file is read, the 
application must delete the file. The EDI translator may 
not build another status file for a given transaction 

10 until the last status file has been erased by the 

application. If the application calls the translator to 
process a transaction without having first erased the 
previous status file for that transaction type, a non- 
zero return code will be posted and the translator will 

15 not accept the call. The content of the status file is 
associated with only one call . The EDI translator may 
not append status information from separate calls into 
one status file. 

The application initiates outbound communication 

2 0 by making a call to the EDI translator. The EDI 
translator responds with a return code of zero to 
indicate a successful operation or a non-zero return code 
to indicate an error. The call structure and the return 
codes are defined for the EDI translator. Only one 

25 interface file may be passed to the EDI translator for 
each call, and only one transaction may be presented in 
each outbound interface file. 

To send an outbound transaction from the 
application to the EDI translator, the application 

30 creates a lock and an interface file using the 

appropriate file name. The application then places the 
segment information in the interface file and turns off 
the lock. The application passes the file name to the 
EDI translator via a call. The EDI translator locks the 

35 file specified in the call and receives the outbound 
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transaction. If the call is successful the EDI 
translator erases the interface file, turns off the lock, 
and posts a return code of zero to the application. If 
the call is unsuccessful the EDI translator turns off the 
5 lock, but will not erase the interface file and a non- 
zero return code is be posted to the application. 
Finally, the application erases the interface file. 

To receive inbound communications from the EDI 
translator, the application polls the system for the 

10 existence of unlocked inbound interface files. The 
inbound interface file may contain one or more 
transactions. The receiving application processes some 
or all of the transactions received in the inbound file. 
Transactions not processed by the application must be 

15 returned to the EDI translator as described below. 

Inbound transactions are sent from the EDI 
translator to the application. If the appropriate 
inbound interface file does not exist, the EDI translator 
will create a lock and a file with the appropriate file 

20 name. If the file already exists, the EDI translator 
will place a lock on the file. The EDI translator will 
place the inbound transaction at the beginning of the 
interface file if the file is new or append the 
transaction to the existing content if the file already 

25 exists. The EDI translator then unlocks the interface 
file. When the application detects the file by polling, 
it places a lock on it. 

An application may process one or more 
transactions in the file. If the application processes 

30 the entire content of the inbound interface file it must 
erase the file and remove the lock. If the application 
does not process all of the transactions in the inbound 
transaction it must delete all segment associated with 
the transactions it processed. The lock will then be 
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removed from the interface file to release it back to the 
EDI translator. 

Other embodiments are within the scope of the 
following claims. 
5 What is claimed is: 
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1. A computer-based method comprising 
creating a first electronic representation of 

binary content of an image of a financial instrument in 

accordance with a predefined data structure, 
5 processing the first electronic representation to 

generate a digital delivery format complying with a 

common delivery protocol, and 

delivering the digital delivery format over an 

electronic data communication network. 



10 2. The method of claim 1 further comprising 

converting the digital delivery format to a second 
electronic representation complying with a second 
predefined data structure protocol. 

3. The method of claim 2 in which the predefined 
15 data structures are the same. 

4. The method of claim 2 further comprising 
processing the second electronic representation. 

5. The method of claim 4 in which the processing 
comprises displaying an image of the financial 

20 instrument. 

6. The method of claim 4 in which the processing 
comprises printing an image of the financial instrument. 

7. The method of claim 1 in which the first 
electronic representation is created at a first financial 

25 institution and the digital delivery format is delivered 
to a second financial institution or merchant. 



8. The method of claim 7 in which the common 
protocol comprises a protocol recognized in common by the 
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first financial institution and the second financial 
institution. 

9. The method of claim 7 in which the first 
predefined data structure comprises a proprietary data 

5 structure of the first financial institution. 

10. The method of claim 1 in which the first 
electronic representation comprises an image of the 
financial instrument . 

11. The method of claim 1 in which the first 
10 electronic representation comprises a digital codeline 

representation of the financial instrument. 

12. The method of claim 1 in which the financial 
instrument comprises a check. 

13. The method of claim 1 in which the financial 
15 instrument comprises a credit card slip. 

14 . The method of claim 1 in which the common 
protocol comprises a commonly accepted protocol. 

15. The method of claim 1 further comprising 
storing the first electronic representation for 

2 0 subsequent retrieval upon a request. 

16. The method of claim 15 in which the first 
electronic representation is stored at a first financial 
institution. 



17. The method of claim 16 in which the request 
25 is delivered electronically to the first financial 
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institution from a second financial institution and the 
digital delivery format is delivered to the second 
financial institution. 

18. The method of claim 16 further comprising 

5 processing the first electronic representation at 

the first financial institution. 

19. The method of claim IB in which the 
processing comprises displaying an image of the financial 
instrument . 

10 20. The method of claim 18 in which the 

processing comprises printing an image of the financial 
instrument . 

21. The method of claim 15 in which the request 
is generated automatically. 

15 22 . The method of claim 15 further comprising 

assigning the first electronic representation an 
identi 1 icat ion index . 

23. The method of claim 22 in which the request 
comprises the identification index. 

20 24 . The method of claim 1 further comprising 

encrypting the digital delivery format for secure 
delivery over the electronic data communication network. 

25. Apparatus comprising 

a capture device for obtaining a first electronic 
25 representation of a financial instrument complying with a 
first protocol, 
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a translator for converting the first electronic 
representation into a digital delivery format complying 
with a second protocol, and 

means for delivering the digital delivery format 
C over an electronic data communication network. 

26. The apparatus of claim 25 in which the first 
electronic representation comprises an image of the 
financial instrument . 

27. The apparatus of claim 25 in which the first 
10 electronic representation comprises a digital codeline 

representation of the financial instrument . 

28. The apparatus of claim 25 in which the 
financial instrument comprises a check. 

29. The apparatus of claim 25 in which the 
15 financial instrument comprises a credit card slip. 



30. The apparatus of claim 25 in which the second 
protocol is a commonly accepted protocol . 

31. The apparatus of claim 25 in which the 
capture device comprises a scanner. 

20 32. The apparatus of claim 25 further comprising 

a memory for storing the first electronic 
representation . 

33. The apparatus of claim 32 further comprising 
a workstation for processing the stored first 
25 electronic representation. 
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34. The apparatus of claim 33 in which the 
processing comprises displaying an image of the financial 
instrument . 

35. The apparatus of claim 33 in which the 

5 processing comprises printing an image of the financial 
instrument . 

36. The apparatus of claim 32 in which the 
workstation comprises an interactive display of the first 
electronic representation. 

10 37. The apparatus of claim 25 in which the 

translator comprises an EDI translator. 

38. Apparatus comprising 

means for electronically receiving a digital 
delivery format of a financial instrument complying with 
15 a first protocol, and 

a translator for converting the digital delivery 
format into an electronic representation complying with a 
second protocol . 

39. The apparatus of claim 38 in which the 
20 electronic representation comprises an image of the 

financial instrument . 

40. The apparatus of claim 3 8 in which the 
electronic representation comprises a digital codeline 
representation of the financial instrument. 

25 41. The apparatus of claim 38 in which the 

financial instrument comprises a check. 
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42. The apparatus of claim 38 in which the 
financial instrument comprises a credit card slip. 

43. The apparatus of claim 38 in which the first 
protocol comprises a commonly accepted protocol . 

5 44. The apparatus of claim 38 in which the 

translator comprises an EDI translator. 

45. The apparatus of claim 34 further comprising 
a workstation for processing the second electronic 
representation. 

10 46. The apparatus of claim 45 in which the 

processing comprises displaying an image of the financial 
instrument . 

47. The apparatus of claim 45 in which the 
processing comprises printing an image of the financial 

15 instrument. 

48. The apparatus of claim 45 in which the 
workstation comprises an interactive display of the first 
electronic representation. 

49. A method for truncating a paper check in a 
2 0 check clearance system comprising 

capturing an electronic image of the paper check 
at a first banking institution, the electronic image 
complying with a first protocol, 

converting the electronic image to a digital 
25 delivery format complying with a common second protocol, 

sending the digital delivery format digitally from 
the first banking institution to a second banking 
institution, 
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at the second banking converting the digital 
delivery format to an electronic image complying with a 
third protocol, and 

processing the electronic image complying with the 
5 third protocol for clearance purposes. 

50. The method of claim 49 in which the digital 
delivery format comprises a secure format created by 
encryption. 

51. A method for use by financial institutions 
10 with respect to financial instruments comprising 

storing, at different financial institutions, 
electronic images of paper financial instruments 
presented to the respective institutions, the storing at 
different financial institutions being done in accordance 

15 with different protocols, 

at each of the financial institutions, accepting 
electronic requests for copies of specified ones of the 
electronic images stored at the respective financial 
institutions, the requests being sent by any of the 

20 financial institutions via a common communication 
network, and 

at each of the financial institutions, responding 
to electronic requests by converting the requested 
electronic images to a common protocol and returning the 
25 images in digital form to the requesting financial 
institution . 

52. The method of claim 51 in which the 
electronic requests are generated automatically. 

53. The method of claim 1 further comprising 

30 automatically processing the binary content of the image 
to verify the authenticity of the item. 



NSDOCID:<WO &722060A1 I > 



WO 97/22060 



PCTAJS96/20358 



- 37 - 

54 . The method of claim 1 further comprising 
automatically processing the binary content to identify 
characters on the financial instrument. 



55. The method of claim 53 in which the 

5 processing includes using cryptography for determining 
authenticity . 

56. The method of claim 1 further comprising 
automatically processing the binary content to identify 
handwritten information. 



10 57. The method of claim 53 further comprising 

marking the financial instrument with an authenticity 
flag and automatically processing the binary content to 
identify the authenticity flag. 



58. The method of claim 1 further comprising 
15 automatically processing the binary content to determine 
if the financial instrument had been altered without 
author i zat ion . 



59. A method comprising 

storing binary content of images of financial 
2 0 instruments in accordance with a predefined data 

structure and information uniquely identifying each of 
the images, 

encapsulating the binary content of each of the 
images in a delivery package that complies with a common 
2 5 protocol, and 

in response to a request for images having 
specified identifying information, sending packages 
containing the binary contents of the images in digital 
form. 



JSOOCID: <WO 9722060A1_I_> 



WO 97/22060 



PCT/US96/20358 



- 38 - 

60. The method of claim 1 in which the processing 
of the first electronic representation includes selecting 
only snippets of the binary content for inclusion in the 
digital delivery format. 
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COMMUNICATION OF IMAGES OF ELECTRONIC 
FUNDS TRANSFER INSTRUMENTS 

Background 

5 The invention relates to communication of images 

of electronic funds transfer instruments. 

As seen in Fig. 1 # payment of a financial 
instrument 10 is normally effected when a first banking 
institution 12 presents the instrument to a second 

10 banking institution 14. The second banking institution 
authenticates the instrument and transmits payment 16 to 
the first banking institution. Presentment of financial 
instruments among banking institutions may also involve 
intermediate steps, such as routing the instrument 

15 through a clearing house 18. 

When the instrument is a written paper check 20, 
as in Fig. 2, a payer 22 presents the check to a payee 24 
during a transaction (such as a sale of goods or 
services) . The check indicates the name of the payee 26, 

2 0 an amount payable 28, a courtesy amount 29, the date 30 
the check was created, the printed name of the payer 32, 
the name of the payer's bank 34, the number of the 
payer's account 36 at the payer's bank, the payer's 
signature 38, check routing information 40, and a MICR 

25 line- 3 9 which is a magnetic coding of some of this 

information. Essentially, the check directs the payer's 
bank to remove the indicated amount 28 from the payer's 
account and to pay that amount upon presentment of the 
check to the payer's bank. 

30 The payee places his signature 42 on the back of 

the check and deposits the check with the payee's bank 44 
with an instruction that payment be made to his account 
46. The check is then routed to the payer's bank 34 
through a clearing house 18, a federal reserve bank or 

35 other established clearing arrangement. This procedure 



>IS0OCID: <WO 9722060A1JA> 



WO 97/22060 PCT/US96/20358 



- 2 - 

for effectuating payment between banks is known as 
forward check presentment. 

The payer's bank verifies the authenticity of the 
check and (at least for some checks) the signature 3 8 of 
5 the payer. If the check is authentic and the payer has 
sufficient funds in his account 36 to cover the amount of 
the check 28, the payer's bank debits the payer's account 
and transfers funds to the payee's bank in the amount 
designated on the check as payment 16. 

10 A check typically is considered authentic if it 

contains the signature 3 8 of the payer, the printed 
identification of the payer 32 and the printed name of 
the payer's bank 34, and does not appear to be altered. 
If the check looks authentic, the payee's bank 

15 provisionally credits the payee's account 46 for the 
amount designated on the face of the check 2 8 pending 
clearance, and acceptance and payment by the payer's 
bank. The payee's bank credits the payee's account when 
the payee's bank receives payment from the payer's bank. 

2 0 This procedure is known as check posting. 

A complete check transaction thus includes 
verification steps performed by the payer's and payee's 
banks 34 and 44. Processing a paper check requires time 
as the physical check is routed from the payer, to the 
25 payee, then to a clearing house, federal reserve bank or 
the payee's bank directly, and finally to the payer's 
bank. The same is true of other types of financial 
transactions involving paper instruments, such as credit 
card slips generated during a credit card sale. In a 

3 0 credit card transaction, a merchant makes an impression 

of the customer's card, which the customer then signs, to 
function as a receipt for the transaction. 

An important function of check processing relates 
to "exception" cases, such as a check returned due to 
35 insufficient funds in the payer's account. Since 
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exception processing provides for dealing with a problem 
in the normal flow of a check through the system, the 
physical check itself may need to be seen in order to 
resolve the problem. In this case, the paper check is 
5 routed back to the payee's bank or the bank of first 
deposit . 

Several mechanisms for using electronic 
communication to substitute for paper flow in financial 
transactions are in use or have been proposed. In 

10 particular, electronic presentment of checks is a 

mechanism used to aid in clearing checks collected by 
banks prior to or without routing the physical checks. 
Electronic Data Interchange (EDI) is an electronic 
transactional system in which funds are frequently 

15 transferred over existing financial networks. 

Check imaging is an electronic transaction 
procedure involving the scanning of a paper check by a 
scanner. The scanner digitizes the image of the check 
pixel by pixel and stores the image electronically in a 

2 0 memory. The image may then be transferred electronically 

to substitute for or precede the physical delivery of the 
check, i.e. to truncate the clearing process. The image 
of the check also may be recreated on a computer monitor 
or on paper for verification by the appropriate banking 

25 institution. 

Each bank may have its own system for capturing 
check images. A critical element of the interchange of 
check images is the ability to determine where and how an 
image can be obtained whenever it is needed. 

30 Summary 

In general, in one aspect, the invention features 
a computer-based method in which a first electronic 
representation of a financial instrument complying with a 
first protocol is created. The first electronic 

3 5 representation is converted to a digital delivery format 
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complying with a second protocol. The digital delivery 
format is delivered over an electronic data communication 
network. This enables information concerning the 
financial instrument to be delivered over the network in 
5 a pre-determined format. 

Implementations of the invention may also include 
one or more of the following features. The digital 
delivery format may be converted to a second electronic 
representation complying with a third protocol . The 

10 third protocol may be the same as the first protocol . 
The second electronic representation may also be 
processed. The processing may include displaying an 
image of the financial instrument or printing an image of 
the financial instrument. 

15 The first electronic representation may be created 

at a first financial institution and the digital delivery 
format delivered to a second financial institution. (In 
this application, whenever we use the words financial 
institution we mean them to include "merchants" . ) The 

2 0 second protocol may be a protocol recognized in common by 
the first financial institution and the second financial 
institution. The first protocol may also include a 
proprietary protocol of the first financial institution. 
The second protocol may include a commonly 

25 accepted protocol. 

The first electronic representation may include an 
image of the financial instrument or a digital codeline 
representation of the financial instrument. 

The financial instrument may be a check or a 

30 credit card slip. 

The first electronic representation may be stored 
for subsequent retrieval upon a request. The first 
electronic representation may be stored at a first 
financial institution. The request may be delivered 

35 electronically to the first financial institution from a 
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second financial institution and the digital delivery 
format delivered to the second financial institution. 
The first electronic representation may be processed at 
the first financial institution. The processing may 
5 include displaying an image of the financial instrument 
or printing an image of the financial instrument. The 
request may be generated automatically. The first 
electronic representation may be assigned an 
identification index. The request may include the 
10 identification index. 

The digital delivery format may be encrypted for 
secure delivery over the electronic data communication 
network. 

In general, in another aspect, the invention 

15 features apparatus including a capture device for 
obtaining a first electronic representation of a 
financial instrument complying with a first protocol, a 
translator for converting the first electronic 
representation into a digital delivery format complying 

20 with a second protocol, and means for delivering the 
digital delivery format over an electronic data 
communication network. 

Implementations of the instrument may include one 
or more of the following features. The first electronic 

25 representation may include an image of the financial 
instrument or a digital codeline representation of the 
financial instrument. The financial instrument may be a 
check or a credit card slip. The second protocol may be 
a commonly accepted protocol. The capture device may 

3 0 include a scanner. The translator may include an EDI 
translator. 

A memory may be included to store the first 
electronic representation. A workstation may be included 
for processing the stored first electronic 
35 representation. The processing may include displaying an 
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image of the financial instrument or printing an image of 
the financial instrument. The workstation may include an 
interactive display of the first electronic 
representation. 
5 In general, in another aspect, the invention 

features apparatus including means for electronically 
receiving a digital delivery format of a financial 
instrument complying with a first protocol, and a 
translator for converting the digital delivery format 
10 into an electronic representation complying with a second 
protocol . 

Implementations of the invention may include one 
or more of the following features. The electronic 
representation may include an image of the financial 
15 instrument or a digital codeline representation of the 
financial instrument. The financial instrument may be a 
check or a credit card slip. The first protocol may 
include a commonly accepted protocol . The translator may 
include an EDI translator. 

2 0 A workstation may be used to process the second 

electronic representation. The processing may include 
displaying an image of the financial instrument or 
printing an image of the financial instrument. The 
workstation may include an interactive display of the 
25 first electronic representation. 

In general, in another aspect, the invention 
features a method for truncating a paper check in a check 
clearance system by capturing an electronic image of the 
paper check at a first banking institution, the 

3 0 electronic image complying with a first protocol, 

converting the electronic image to a digital delivery 
format complying with a common second protocol, sending 
the digital delivery format digitally from the first 
banking institution to a second banking institution, at 
3 5 the second banking converting the digital delivery format 
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to an electronic image complying with a third protocol , 
and processing the electronic image complying with the 
third protocol for clearance purposes. 

Implementations of the invention may include the 
5 following feature. The digital delivery format may 
include a secure format created by encryption. 

In general, in another aspect, the invention 
features a method for use by financial institutions with 
respect to financial instruments including storing, at 

10 different financial institutions, electronic images of 
paper financial instruments presented to the respective 
institutions, the storing at different financial 
institutions being done in accordance with different 
protocols, at each of the financial institutions, 

15 accepting electronic requests for copies of specified 
ones of the electronic images stored at the respective 
financial institutions, the requests being sent by any of 
the financial institutions via a common communication 
network, and at each of the financial institutions, 

2 0 responding to electronic requests by converting the 
requested electronic images to a common protocol and 
returning the images in digital form to the requesting 
financial institution. 

Implementations of the invention may include the 

25 following feature. The electronic requests may be 
generated automatically. 

The invention relates to the communication of 
binary content images of funds transfer instruments 
between banks. Each bank wraps the binary content in the 

30 bank's own proprietary format. A transmitting bank 
packages the proprietary format containing the binary 
content within a standard message format. The receiving 
bank uses the elements of the standard message format to 
find and interpret the binary content for use or display. 
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Advantages of the invention may include one or 
more of the following. 

Many business functions could benefit from check 
image interchange, including signature verification and 
5 stop payment orders and/or payer information. The 
interchange of images in addition to the electronic 
interchange of check codeline data allows truncation to 
be possible. 

The invention addresses the problem of check image 
10 interchange without physically exchanging paper checks. 
The invention provides an electronic communication 
alternative for check image transfer. 

The invention enhances the electronic presentment 
of checks with the addition of check images. Critical 
15 business flows are rearranged and altered. The invention 
also provides a new way to implement check processing to 
truncate the flow of paper checks. In addition, the 
invention provides a system for locating check images 
among the 15,000 banking institutions in the United 
20 States. Check images may be transported routinely or on 
demand . 

The invention provides integration of existing 
banking systems to facilitate check processing. The 
existence of these systems will allow for implementation 

2 5 and acceptance by the banking industry. 

The invention to a degree electronically mimics 
heavily-used and well -understood existing paper check 
processes to enable it to be readily accepted by the 
banking industry. By retaining the basic characteristics 

30 and flexibility of, e.g., the paper check, the invention 
may be adopted more rapidly. Due to the similarity with 
exchanging paper checks, the invention can be used within 
the structure of existing laws, regulations, and standard 
banking practices. 
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Since the system can be fully automated, and new 
processing can be done outside of existing applications, 
the cost of electronic check image interchange may be 
lower, and the costs of implementation minimized. To 
5 further minimize implementation costs, check image 

interchange may be integrated with the existing banking 
infrastructure, including some of the mechanisms 
currently used, such electronic presentation of checks. 

The use of electronic check image interchange will 
10 be more cost effective than existing paper checks due to 
volume efficiencies and the automatic processing 
capabilities of computers. The use of electronic 
transmission is less costly than physically transporting 
paper. Banks may significantly reduce the costs of 
15 mailing and/or transporting paper checks, such as for 
envelopes, stamps, and incremental labor. 

Other advantages and features of the invention 
will become apparent from the following description and 
from the claims. 
2 0 Description 

Figure 1 is a block diagram of a financial 
transaction. 

Figure 2 is a flow diagram of the steps of a check 
transaction. 

25 Figure 3 is a block diagram of a network of 

financial institutions . 

Figure 4 is a block diagram of a bank's check 
image interchange system. 

Figure 5 is a flow diagram of a check presentment 
30 application. 

Figure 6 is a flow diagram of a check query 
application. 

Figure 7 is a block diagram of a check image 
interchange system . 
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Figure 8 is block diagram of the functional groups 
of the ANSI X9.46 proposed standard. 

Figure 9 is a block diagram of a data structure 

scheme. 

5 As seen in Fig. 9, the invention provides an 

instrument image interchange facility 500. At one 
institution 4 98, a paper instrument 501 is scanned and 
stored using a conventional data structure 503 to capture 
the binary image content 504. Typical such structures 

10 include JPEG, CCITT Group IV, and IBM's ABIC. The 
instrument image interchange would require that the 
binary content of the image be kept in one of these 
formats or some other preapproved form. It also requires 
that the binary content be encapsulated (i.e., packaged 

15 or enveloped) in a preapproved common data structure 506, 
for example one complying with ANSI proposed standard 
X.9. If both of these requirements are met then the 
packaged data structure may be sent via any communication 
mode to any other institution which can then reliably 

20 recover and use the binary content of the instrument 
image by means of a readily available, easily defined 
algorithm. The data structure may also enclose 
information 510 from proprietary data structures 
associated with the binary content so long as it also 

2 5 includes the standard forms of data structure 

information. 

In current schemes it is common for an institution 
to envelope binary content in a proprietary envelope for 
various purposes, such as the IOCA scheme of IBM. The 

3 0 invention does not prevent continued use of such 

arrangements at each institution nor the inclusion of 
proprietary data structure information in what is sent 
between institutions, but it provides an alternative 
approach that permits fluid interchange of image content 
3 5 anywhere in the world via a wide variety of communication 
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media and among a wide variety of institutions for a wide 
variety of purposes without any two of the institutions 
having to engage in special negotiations to achieve the 
result. Each institution is able to rely on the common 
5 structures as assuring its ability to participate in the 
system. 

As shown in Fig. 3, banking institutions 50 may 
interchange check images via a network 52, such as a 
distributed TCP/IP based network. A TCP/IP network could 

10 utilize dial-up ISDN, for example. Electronic networks 
include the dial-up, Internet, wireless, and e-mail 
networks. Since security is critical for communication 
of electronic funds transfer instruments, established 
banking networks, which are secure and well disciplined, 

15 may be preferred to public networks. 

Each banking institution is a node on the network 
52 and has a server 54 (e.g., a UNIX server), a local 
image store 56 and a workstation 58 such as a personal 
computer with a monitor. Through the network, any one of 

2 0 these components in one bank may communicate with any 
other component in a bank connected to the network, 
whether or not the components are at the same location or 
geographically separated. 

In Fig. 4, bank 50 has an image capture system 62 

25 connected to its server. The bank which captures a check 
image is known as the bank of first image. The image 
capture system includes a scanner 64 for obtaining an 
electronic digital image of both sides of a check and for 
deriving codeline data from the check such as the payee, 

30 the payer, the payer's bank, the payer's bank account and 
the amount to be paid. The check may also include an 
imprint of a unique identifier for the check such as a 2D 
bar code which would allow tracking of the check by 
analyzing its image. The image capture system 62 may be 

35 a known proprietary system chosen by the bank, such as 
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the High Speed Image Item Processing System available 
from Unisys. The codeline data may be converted to an 
format for electronic presentment of checks by a 
processing system 66, which may be connected to the 
5 bank's server. 

The digital check image and the codeline data are 
stored in a data store 56 known as an archive. The bank 
may transmit both the codeline data from the check and 
the check image data over the same network, although the 
0 codeline data and the check image need not be transmitted 
together. The archive 56 stores the data in a 
proprietary format chosen by the bank, such as the Image 
Object Content Architecture (IOCA) format of IBM or the 
Tag Image File format (TIFF) used by Unisys. 
5 Check image interchange involves a set of 

applications which provide user interfaces for banks to 
request check images from other remote banks, receive 
images from other remote banks, and provide images to 
other banks upon request. Two check image interchange 
) applications concern forward check presentment and image 
queries. The applications manage the resources required 
to process the queries, responses and acknowledgements 
associated with check image interchange. 

The bank 50 has at least one workstation 58 for 
5 formulating and managing image queries to remote banks 
and for viewing retrieved check images by an operator. 
The bank may also support other applications 75, 
including its own use of the stored check images and 
codeline data such as for processing and viewing. 
► In an alternative embodiment, check images and 

data may be captured and stored by a third party 
repository 57. The repository would provide an archive 
server 59 for access to the stored check images and data 
by other banking institutions. 
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The applications must support communication of 
check images and requests in a standard format since each 
bank employs its own chosen proprietary image capture and 
storage systems. The communications standard chosen for 
5 check image interchange is the ANSI X9.4 6 proposed 

standard. The mechanisms for routing check images and 
requests between banks and for searching for images 
utilize the X9.46 proposed standard for the entire 
interchange process . Although forward presentment of 

10 codeline data alone may be performed either with a 

commercially available product for electronic presentment 
of checks or using the X9.46 proposed standard, use of 
the X9.4 6 proposed standard will be assumed tor present 
purposes. Details of the X9.46 proposed standard are set 

15 forth in the ANSI X9.46 Data Structure Reference, 

available from the X9B working group within ANSI and 
incorporated by reference. 

A system known as Image Locator Services (ILS) 72 
located in the bank as part of its server processes check 

2 0 image data, codeline data and query requests from the 

bank's proprietary format into the X9.46 proposed 
standard format for communication with other banks. A 
commercially available EDI translator 74 within the ILS 
may be used to perform the translation. The ILS 
25 determines where data is to be routed in the interbank 
exchange environment and provides the communications 
mechanisms needed to transmit information in the standard 
format. The check image interchange applications include 
information required to build the content of X9.46 query, 

3 0 image and acknowledgement messages and transmit them to 

and receive them from the EDI translator 74 via an 
application interface. 

As shown in Fig. 5, in forward check presentment 
100, check images and codeline data are captured (step 
35 102) using the bank's existing proprietary capture 
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equipment. The captured data is placed in an image 
archive in the bank's proprietary format (step 104). 

After capture, the codeline data from the checks 
must be packaged and sent to the payer's bank to initiate 
5 payment procedures. A codeline data file is created 

(step 106) which includes information for requesting the 
corresponding check images and the codeline data from 
which images to be viewed can be identified. For 
example, the codeline data file contains an image 

10 identifier corresponding to the stored check image. The 
codeline data is then sent to the ILS (step 108) . 

The ILS translates the codeline data file to the 
X9.46 proposed standard format and bundles it into an 
X9.46 data file {step 110). The translation process maps 

15 the file into an X9.46 data stream to send to the payer's 
bank. The codeline data may be sent by itself, or with 
the corresponding check image or portions of check image. 
Or, as described below, the check image data may be 
transmitted by itself. 

2 0 The ILS also determines the recipient of the 

translated codeline data (step 112) . Thus, the 
information sent to the ILS must contain enough 
information to identify the receiving institution. The 
ILS then determines the details for transmitting the 

2 5 translated file to the recipient bank, including the 

phone number to dial, the network address, and/or the e- 
mail address. 

The ILS executes the transmission to the recipient 
bank (step 114), and the recipient bank's ILS receives 

30 the transmission of the codeline data in the X9.46 
proposed standard format (step 116) . 

The recipient bank's ILS determines the nature of 
the X9.46 data stream it has received (step 118) and 
identifies which internal system is to receive the 

35 codeline data. Knowing this information, the ILS 
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translates the codeline data into a format usable by the 
internal system of the recipient bank (step 120) . 

The ILS interfaces the translated codeline data 
file with the appropriate system for processing (steps 
5 122 and 124) . Although each bank may treat the codeline 
data differently, the codeline data ultimately is passed 
on to the appropriate internal posting system to complete 
payment of the check. However, at this time, not all 
banks post checks with electronic presentment of checks. 

10 Thus, the result of the check presentment procedure is 

the identification of images that the recipient bank must 
request. Usually this is done to research problem items 
that cannot be posted directly from the codeline data for 
various reasons. Also, research may need to be done to 

15 handle other exception conditions such as stop payment 
orders, non- sufficient funds, closed accounts, etc. The 
result of the check posting procedure may be a report of 
check images to be examined or a list of items to be used 
in an automated query. 

20 In Fi 9- 6 ' in the check query application 130, two 

strategies may be employed to accomplish a query. For a 
single item real time query (step 132), the operator 
enters the image identifier of the desired check image. 
The query for images to be viewed may also be 

25 formulated in advance and stored in a pick list to be 
batch processed (step 134) . For example, the exception 
processes may generate the pick list, or the operator may 
enter the image identifiers from a report. Received 
images may then be stored locally for off-line viewing. 

30 If the exception processes automatically generate the 
query, then the query can be carried out without any 
action by the operator, and the images would be ready for 
viewing when the operator is available. 

The processes generating the queries send the 

35 query request in the bank's proprietary format to the ILS 
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of the requesting bank (step 136) . The ILS translates 
the query request into an X9.46 data file (step 138) . 
The ILS also determines what system has sent the query 
request to determine which map to use for the 
5 translation. 

The ILS determines the recipient of the query 
request (step 140) . Thus, the information sent to the 
ILS must contain enough data to identify the institution 
to receive the request. The ILS determines the details 

10 for transmitting the request file to the bank that 

created the image, including the phone number to dial, 
the network address, and/or the e-mail address. The ILS 
then executes the actual transmission to the bank of 
first image (step 142) . 

15 When the bank of first image's ILS receives the 

transmitted query request (step 144), it determines the 
nature of the X9.4 6 data stream it has received (step 
146) and identifies which internal system (e.g., the 
archive) is to receive the query request data. The ILS 

20 translates the query request into a format usable by the 
archive of the bank of first image (step 148) . 

The bank of first image's ILS interfaces the 
translated query request with the archive to service the 
request (step 150) . The archive attempts to find the 

25 requested images and/or data (step 152) . The archive 
sends the completed response ( images, data, or error 
information) back to the ILS (step 154) . 

The ILS of the bank of first image determines 
which internal system has sent the data to it to 

3 0 determine which map to use for the translation, and then 
translates the response into an X9.46 data file (step 
156) . 

The bank of first image's ILS determines the 
recipient of the query response (step 158) . Thus, the 
3 5 information sent to the ILS must contain enough data to 
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identify the requesting bank. The ILS then attends to 
the details for transmitting the file to the requesting 
bank, including the phone number to dial, the network 
address, and/or the e-mail address. The ILS executes the 
5 transmission of the X9.46 file to the requesting bank's 
ILS (step 160) . 

When the ILS of the requesting bank receives the 
transmitted query response (step 162), it determines the 
nature of the X9.46 data stream it has received (step 
10 164) and identifies which internal system should receive 
the query response data. The ILS translates the query 
response into a format usable by the internal system 
(e.g., the workstation) (step 166). The workstation at 
the requesting bank displays the received images (step 
15 168), or the images and data received are stored for 
later inspection (step 170) . 

Applications for check image interchange have been 
developed by IBM and Unisys. The check image interchange 
components are provided on hardware and software 
20 platforms such as RISC/6000 for the IBM AIX system and 
U6000 for the Unisys UNIX system, as well as platforms 
for the EDI translator. Connection to the network may be 
accomplished through network boxes such as an Adtran 12 8 
DSU modem for ISDN connectivity and Cisco 2 502 access 
25 routers for LAN connectivity to ISDN equipment. These 

have been used in pilot experiments. Any scheme that can 
establish a TCP/IP network may be used. 

The image capture system captures both the 
electronic digital images and the codeline data for 
30 checks. The scanners that may be used range from high 
speed reader/sorters such as those available from Unisys, 
AT&T and IBM, to low speed desktop scanners such as those 
available from Hewlett-Packard. In some systems, the 
codeline information is entered by the operator rather 
35 than through the scanning operation. 
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The image capture system exports the captured 
information to the archive and generates index 
information used for identification. The index 
information ideally includes the item sequence number, 

5 the cycle indicator (day of the week) , the processing 
data, and the initial storage device number. For 
convenience, export of information also should be 
controllable by other useful selection criteria such as 
sorter job. If the image capture system does not perform 

0 these functions, it must allow the archive system to 

access the information so that the data can be stored and 
indexed. Alternatively, the capture system may be 
integrated into the archive system for ease of storage 
and indexing. 

5 The number of views presented to the requesting 

bank for each request corresponds to the number of views 
captured by the bank of first image's image capture 
system. Check image interchange may support varied image 
views, such as front black-white, front gray scale, back 

0 black-white and back gray scale. 

Storage and communication of check images is 
carried out in the compressed image format of the bank of 
first image. The image data compression algorithm used 
is determined by the binary image format of the bank of 

5 first image. Image data may be formatted using accepted 
compression algorithms, which include Adaptive Bilevel 
Image Compression (ABIC) by IBM, and CCITT Group 4 and 
the Joint Photographic Experts Group (JPEG) used by 
Unisys and AT&T. No image data conversion takes place 

0 prior to or during communications, and the receiving 
system converts the image as needed or desired. 

The use of electronic presentment of checks allows 
check data to be interchanged in real time and at volumes 
that current technology, price and performance can 

5 accommodate. By sending the data in codeline data format 
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(which may also contain an identification label of the 
associated image) , the receiving bank can process the 
data, post the check, and be assured of resolving 
discrepancies with the data and handling exception 
5 conditions in a timely manner by accessing the check 
image from the bank of first image. In some cases, the 
actual check images will be forward presented, such as 
for items not qualified for processing of electronic 
presentment of checks or where the condition of the check 

10 would dictate a need by the recipient for the image. The 
receiving bank can resolve the problem causing the 
exception by viewing the image and making the necessary 
repairs to the data. 

The components of the ILS are constructed on a 

15 server, such as a UNIX-based server. The software 
components required to implement image capture and 
transfer through the ILS include the applications and the 
EDI translator. These software components enclose and 
optionally encrypt, perform hashing on, and provide a 

20 digital signature (if one does not already exist) for the 
compressed image in a ANSI X9.4 6 proposed standard 
envelope that identifies the image format and contains 
various pieces of data pertinent to the image, such as 
the index information. A digital signature may already 

2 5 exist prior to the processing; if so, the digital 

signature is simply passed through. The EDI translator 
maintains communication session control between the banks 
exchanging data in X9.46 proposed standard format. 

The EDI translator in the ILS constructs X9.4 6 

3 0 messages based on information received from the 

processing system, the archive and the workstation, and 
passes information received in X9.46 proposed standard 
format to these systems. Data is passed between the EDI 
translator and the other systems using an application 
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interface, which may include sockets, named pipes, Files, 
FTP, e-mail or other means. 

Image data, for example, is provided to the EDI 
translator in TIFF, IOCA or another image encapsulation 
5 data structure via the application interface. The EDI 
translator opens the image content and constructs the 
X9.4 6 interchange object based on the control data and 
the image binary data contained in the image object. 
Conversely, the EDI translator assembles image data 
10 received in an X9.46 data stream into TIFF or IOCA image 
objects as specified by the receiving bank's application. 

The archive provides a repository of check images 
and codeline data. The archive includes all the 
processing data elements necessary to locate images and 
15 codeline data from queries made to the system, including 
the item sequence number, processing date, cycle number, 
and device identification. Other financial data storage 
requirements may include the MICR line of the check, the 
bank of first deposit and document image number, the date 
2 0 the check was paid, and the disposition of the check. 
The images of the front and back of the check may be 
stored in their original capture format or in an export 
format that includes the data compression and an image 
wrapper . 

25 The archive interfaces with the ILS to perform the 

query function. The archive normally will be used both 
for check image interchange and for check processing such 
as normal proof of deposit operations. Alternatively, 
there may be a separate archive used solely for 

30 interchange or other functions. 

The archive system must be capable of receiving or 
importing images and data from the capture system. This 
exchange may be via seamless integration or a data export 
type of interface. The process of storing may occur in 

35 real time during capture, or in some cases it may be a 
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separate export process that takes place subsequent to 
capture. Further, some aspects of data integrity and 
.security may be implemented within the archive system. 

The workstation provides a user interface for 
5 querying and displaying images. The workstation may 
support the entry of an image identifier for queries as 
well as imbedding the query functions into the various 
business applications that utilize check images, such as 
exception processing and signature verification. Upon 
10 entry of user data needed to formulate a query, the 
formatting routines of the workstation's software 
establish a query transaction to be transmitted to the 
ILS. Examples of workstation platforms are Windows and 
OS/2 Warp. 

15 The images returned to the workstation from the 

ILS after a query request are in the data format used by 
the bank of first image. No transcoding is done by the 
bank of first image. Thus, the display system of the 
workstation must be able to understand all of the 

2 0 accepted standard image formats. The workstation has 

software to decompress and decode received image formats, 
such as Image Viewer. 

Additional details of the check imaging system are 
shown in Fig. 7. 

25 As shown in Fig. 8, the ANSI X9.4 6 proposed 

standard 200 defines several functional groups for 
exchanging image information and coded data. 

The query request functional group 2 02 is used by 
the requesting bank to request one or more images from 

30 the bank of first image. Each query contains a unique 
query ID 2 04 for maintaining continuity between the 
original query, acknowledgment and the transmission of 
images to the requesting bank. 

The query request functional group 202 permits an 

35 image to be specified individually, based on its image 
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identifier, or to be specified based upon generalized 
search criteria such as account number and serial number 
range. The requesting bank also may request check image 
formats that conform to its viewing software. Additional 
5 query request elements may include snippets of the check 
image, scaling and color. 

The items views functional group 206 is used to 
return image items requested by the requesting bank. 
This functional group supports transmission of one or 

10 more images. Item data loop structures 208 contain the 
information for imaged items. Multiple item data loops, 
each representing a single image, may exist within the 
functional group. Within each item data loop, one or 
more item view loops may exist to represent different 

15 views of the image. Therefore, a single transmission of 
an item views functional group may contain multiple 
images, each of which may further contain multiple views. 
The views available to be sent to the requesting bank 
depend upon which views were captured by the bank of 

2 0 first image. 

The financial data functional group 210 is used to 
convey check codeline and other associated financial 
data. 

The application acknowledgment functional group 
25 212 provides a positive or negative application 

acknowledgment 214 that the content of the information 
received in an exchange is functionally correct and 
acceptable to the recipient. An application 
acknowledgment 214 may be requested in response to the 
30 transmission of a query request functional group 202, an 
item views functional group 206 or a financial data 
functional group 210. 

The functional acknowledgment functional group 216 
provides a positive or negative functional acknowledgment 
35 218 that the information received in an interchange is 
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syntactically correct for a functional group, transaction 
set, or data segment. A functional acknowledgment 218 
may be requested in response to the transmission of a 
query request functional group 202, an item views 
5 functional group 206 or a financial data functional group 
210. Unlike the other functional groups, the information 
in the functional acknowledgment functional group is 
supplied entirely by the EDI translator in response to 
the information received in the context of the functional 

10 group which invoked it; no input from the receiving 

application is required. The EDI translator constructs 
the functional acknowledgment functional group and 
transmits the response back to the requestor without the 
intervention of the application. 

15 The X9.46 proposed standard also supports other 

image capture and transfer functions. The query request 
functional group 202 and the item views functional group 
206 provide a security header which allows 
authentication, encryption services, and digital 

2 0 signatures to be applied to transmission of these groups. 
The X9.46 proposed standard also permits one or more 
transaction sets to be specified for each functional 
group. Additional functional groups and data elements 
may be added at a later date to support an expanded 

2 5 implementation of the X9.4 6 proposed standard. 

The EDI translator accepts source images in either 
the IOCA or TIFF object format, for example, and builds 
X9.4 6 interchange messages which are independent of the 
proprietary systems employed by the bank and which 

3 0 contain the appropriate control and data content, but do 

not rely upon the syntax of the original image data. The 
receiving bank may request that the translator 
reconstruct the image into its original object format, if 
it is known, or reconstruct the image object into a 
3 5 representation chosen by the bank. For example, the 
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sending bank may have provided the image as a TIFF object 
but the receiving bank may wish to reconstruct the image 
as an IOCA object. 

Under normal circumstances it is assumed that the 
5 receiving bank will select a single representation for 
all images it receives, and that the representation will 
be defined in the translator via a configuration table. 
It is also conceivable that the receiving bank may wish 
to dynamically define the format of the images it 
10 receives based on the source of the images. The format 
chosen by the bank will be incorporated into the EDI 
translator. 

The transaction is the basic unit of communication 
with the EDI translator. Each transaction contains the 

15 information necessary to represent the content of an 
X9.4 6 functional group. The. EDI translator uses the 
content of the transaction to construct an X9.4 6 
functional group for outbound transmissions. For inbound 
transmissions, the EDI translator constructs a 

2 0 transaction from the received X9.4 6 functional group. 
The interface with the EDI translator includes pre- 
defined interface files. 

Each X9.4 6 functional group has a pair of 
dedicated interface files for outbound transactions to 

25 the EDI translator and inbound transactions from the EDI 
translator. For example, each interface file has a 
record length of 80 bytes followed by a line feed 
character. Each record within a file represents a 
logical grouping of X9.4 6 data elements, referred to as 

30 segments. A segment consists of a segment identifier and 
the data elements, which may not exceed 80 bytes. The 
segment and data element structure of the outbound and 
inbound interface files is the same. 

A unique set of segments is defined for each EDI 

35 transaction type. These segments represent the mandatory 
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data elements required for each functional group in 
addition to any optional or conditional elements 
necessary for implementation of the applications. New 
segment definitions may be added to incorporate 
5 additional data elements. All interface file segments 
records must be built by the application in the sequence 
specified for a particular transaction type. 

Data elements within a segment have fixed lengths, 
with no delimiters between data elements. Binary data 

10 elements are contained in a separate file whose name is 
contained in a segment data element. The order in which 
data elements appear in the segment may not necessarily 
correspond to the order in which they appear in the X9.4 6 
functional group. All segment data element positions are 

15 present in both outbound and inbound transactions. 

Except where noted, all data elements contain data in 
both outbound and inbound transactions. In those cases 
where the length of a data element may be less than the 
fixed length of the data element field, the data is left- 

2 0 aligned and the unused bytes must be padded with ASCII 

blanks . 

An X9.4 6 loop structure may be represented by a 
single segment or a sequence of segments. Loop 
iterations are specified by repeating the segment or 
25 segments for the required number of iterations. The 

nesting sequence of outer and inner loops is as described 
in the ANSI X9.46 proposed standard specification. Loop 
structures must be constructed in the order described for 
the transaction type. Subordinate loop sequences must be 

3 0 completed before the next higher level loop can be 

repeated. 

A transaction set reference ID 220 is used to 
associate two functional groups. For example, the 
transaction set reference ID is used to associate the 
35 item views transaction to the query request transaction 
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which requested the images. The transaction set 
reference ID of the query request will be inserted in the 
transaction set reference ID of the resulting item views 
transaction to allow the receiving application to 
5 associate the inbound item views transaction with the 
query request transaction that requested the images . 
Since the EDI translator generates the transaction set 
reference ID for all outbound transactions, the 
transaction set reference ID must be returned to the 

10 application in a status file after the EDI translator 
builds the outbound transaction. 

In a transaction, the application sends an 
outbound query to the EDI translator. After building the 
query request transaction, the EDI translator returns the 

15 transaction set reference ID 22 0 to the application in a 
status file. The receiving EDI translator passes the 
transaction set reference ID of the query request 
transaction to the receiving application along with the 
query contents. When the receiving application builds 

2 0 the item views transaction, it passes the transaction set 
reference ID of the query request transaction to the EDI 
translator, which inserts it into the transaction set 
cross reference ID of the item views transaction. This 
associates the item views transaction with the query 

25 request transaction. When it receives the item views 
transaction, the application which sent the query 
extracts the transaction set cross reference ID to 
associate the inbound item views transaction with the 
original query request transarvion. 

30 The EDI translator maii.r.ains two status files 

which will be available to the application after every 
outbound call to the EDI translator, one for results of 
outbound query requests and the other for results of 
outbound item view requests. The status files contain 
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the call status and the transaction set reference ID of 
the transactions created by the EDI translator. 

The EDI translator builds a status file with the 
appropriate file name after processing an outbound 
5 request from the application. The status file is 
available to the application after a return code is 
posted for the call. Once the status file is read, the 
application must delete the file. The EDI translator ma> 
not build another status file for a given transaction 
10 until the last status file has been erased by the 

application. If the application calls the translator to 
process a transaction without having first erased the 
previous status file for that transaction type, a non- 
zero return code will be posted and the translator will 
15 not accept the call. The content of the status file is 
associated with only one call. The EDI translator may 
not append status information from separate calls into 
one status file. 

The application initiates outbound communication 
20 by making a call to the EDI translator. The EDI 
translator responds with a return code of zero to 
indicate a successful operation or a non-zero return code 
to indicate an error. The call structure and the return 
codes are defined for the EDI translator. Only one • 
25 interface file may be passed to the EDI translator for 
each call, and only one transaction may be presented in 
each outbound interface file. 

To send an outbound transaction from the 
application to the EDI translator, the application 
30 creates a lock and an interface file using the 

appropriate file name. The application then places the 
segment information in the interface file and turns off 
the lock. The application passes the file name to the 
EDI translator via a call. The EDI translator locks the 
35 file specified in the call and receives the outbound 
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transaction. If the call is successful the EDI 
translator erases the interface file, turns off the lock, 
and posts a return code of zero to the application. If 
the call is unsuccessful the EDI translator turns off the 
5 lock, but will not erase the interface file and a non- 
zero return code is be posted to the application. 
Finally, the application erases the interface file. 

To receive inbound communications from the EDI 
translator, the application polls the system for the 

10 existence of unlocked inbound interface files. The 
inbound interface file may contain one or more 
transactions. The receiving application processes some 
or all of the transactions received in the inbound file. 
Transactions not processed by the application must be 

15 returned to the EDI translator as described below. 

Inbound transactions are sent from the EDI 
translator to the application. If the appropriate 
inbound interface file does not exist, the EDI translator 
will create a lock and a file with the appropriate file 

20 name. If the file already exists, the EDI translator 
will place a lock on the file. The EDI translator will 
place the inbound transaction at the beginning of the 
interface file if the file is new or append the 
transaction to the existing content if the file already 

2 5 exists. The EDI translator then unlocks the interface 

file. When the application detects the file by polling, 
it places a lock on it. 

An application may process one or more 
transactions in the file. If the application processes 

3 0 the entire content of the inbound interface file it must 

erase the file and remove the lock. If the application 
does not process all of the transactions in the inbound 
transaction it must delete all segment associated with 
the transactions it processed. The lock will then be 
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removed from the interface file to release it back to the 
EDI translator. 

Other embodiments . are within the .scope of the 
following claims. 
5 What is claimed is: 
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1. A computer-based method comprising 
creating a first electronic representation of 

binary content of an image of a financial instrument in 

accordance with a predefined data structure, 
5 processing the first electronic representation to 

generate a digital delivery format complying with a 

common delivery protocol, and 

delivering the digital delivery format over an 

electronic data communication network. 

10 2 - The method of claim 1 further comprising 

converting the digital delivery format to a second 
electronic representation complying with a second 
predefined data structure protocol. 

3. The method of claim 2 in which the predefined 
15 data structures are the same. 

4 . The method of claim 2 further comprising 
processing the second electronic representation. 

5. The method of claim 4 in which the processing 
comprises displaying an image of the financial 

2 0 instrument. 

6 . The method of claim 4 in which the processing 
comprises printing an image of the financial instrument. 

7. The method of claim 1 in which the first 
electronic representation is created at a first financial 

25 institution and the digital delivery format is delivered 
to a second financial institution or merchant. 

8 . The method of claim 7 in which the common 
protocol comprises a protocol recognized in common by the 
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first financial institution and the second financial 
institution . 

9. The method of claim 7 in which the first 
predefined data structure comprises a proprietary data 

5 structure of the first financial institution. 

10. The method of claim 1 in which the first 
electronic representation comprises an image of the 
financial instrument . 

11. The method of claim 1 in. which the first 
10 electronic representation comprises a digital codeline 

representation of the financial instrument. 

12. The method of claim 1 in which the financial 
instrument comprises a check. 

13. The method of claim 1 in which the financial 
15 instrument comprises a credit card slip. 

14 . The method of claim 1 in which the common 
protocol comprises a commonly accepted protocol. 

15. The method of claim 1 further comprising 
storing the first electronic representation for 

20 subsequent retrieval upon a request. 

16. The method of claim 15 in which the first 
electronic representation is stored at a first financial 
institution. 

17. The method of claim 16 in which the request 
25 is delivered electronically to the first financial 
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institution from a second financial institution and the 
digital delivery format is delivered to the second 
financial institution. 

18. The method of claim 16 further comprising 

5 processing the first electronic representation at 

the first financial institution. 

19. The method of claim 18 in which the 
processing comprises displaying an image of the financial 
instrument . 

1° 20. The method of claim 18 in which the 

processing comprises printing an image of the financial 
instrument . 

21. The method of claim 15 in which the request 
is generated automatically. 

15 22 . The method of claim 15 further comprising 

assigning the first electronic representation an 
identification index. 

23 . The method of claim 22 in which the request 
comprises the identification index. 

20 24. The method of claim 1 further comprising 

encrypting the digital delivery format for secure 
delivery over the electronic data communication network. 

25. Apparatus comprising 

a capture device for obtaining a first electronic 
25 representation of a financial instrument complying with a 
first protocol, 
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a translator for converting the first electronic 
representation into a digital delivery format complying 
with a second protocol, and 

means for delivering the digital delivery format 
5 over an electronic data communication network. 

26. The apparatus of claim 25 in which the first 
electronic representation comprises an image of the 
financial instrument . 

27. The apparatus of claim 25 in which the first 
10 electronic representation comprises a digital codeline 

representation of the financial instrument. 

28. The apparatus of claim 25 in which the 
financial instrument comprises a check. 

29. The apparatus of claim 2 5 in which the 
15 financial instrument comprises a credit card slip. 

30. The apparatus of claim 25 in which the second 
protocol is a commonly accepted protocol. 

31. The apparatus of claim 25 in which the 
capture device comprises a scanner. 

20 32. The apparatus of claim 25 further comprising 

a memory for storing the first electronic 
representation. 

33. The apparatus of claim 32 further comprising 
a workstation for processing the stored first 
25 electronic representation. 
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34. The apparatus of claim 33 in which the 
processing comprises displaying an image of the financial 
instrument . 

35. The apparatus of claim 33 in which the 

5 processing comprises printing an image of the financial 
instrument. 

36. The apparatus of claim 32 in which the 
workstation comprises an interactive display of the first 
electronic representation. 

10 37. The apparatus of claim 25 in which the 

translator comprises an EDI translator. 

38. Apparatus comprising 

means for electronically receiving a digital 
delivery format of a financial instrument complying with 
15 a first protocol, and 

a translator for converting the digital delivery 
format into an electronic representation complying with a 
second protocol . 

39. The apparatus of claim 38 in which the 
20 electronic representation comprises an image of the 

financial instrument . 

40. The apparatus of claim 38 in which the 
electronic representation comprises a digital codeline 
representation of the financial instrument. 

25 41. The apparatus of claim 38 in which the 

financial instrument comprises a check. 
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42. The apparatus of claim 38 in which the 
financial instrument comprises a credit card slip. 

43. The apparatus of claim 3 8 in which the first 
protocol comprises a commonly accepted protocol. 

5 44. The apparatus of claim 3 8 in which the 

translator comprises an EDI translator. 

45. The apparatus of claim 34 further comprising 
a workstation for processing the second electronic 
representation . 

10 46 • The apparatus of claim 45 in which the 

processing comprises displaying an image of the financial 
instrument . 

47. The apparatus of claim 45 in which the 
processing comprises printing an image of the financial 

15 instrument. 

48. The apparatus of claim 45 in which the 
workstation comprises an interactive display of the first 
electronic representation. 

49. A method for truncating a paper check in a 
20 check clearance system comprising 

capturing an electronic image of the paper check 
at a first banking institution, the electronic image 
complying with a first protocol, 

converting the electronic image to a digital 
25 delivery format complying with a common second protocol, 

sending the digital delivery format digitally from 
the first banking institution to a second banking 
institution, 
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at the second banking converting the digital 
delivery format to an electronic image complying with a 
third protocol, and 

processing the electronic image complying with the 
5 third protocol for clearance purposes. 

50. The method of claim 4 9 in which the digital 
delivery format comprises a secure format created by 
encryption. 

51. A method for use by financial institutions 
10 with respect to financial instruments comprising 

storing, at different financial institutions, 
electronic images of paper financial instruments 
presented to the respective institutions, the storing at 
different financial institutions being done in accordance 
15 with different protocols, 

at each of the financial institutions, accepting 
electronic requests for copies of specified ones of the 
electronic images stored at the respective financial 
institutions, the requests being sent by any of the 

2 0 financial institutions via a common communication 

network, and 

at each of the financial institutions, responding 
to electronic requests by converting the requested 
electronic images to a common protocol and returning the 
25 images in digital form to the requesting financial 
institution. 

52 . The method of claim 51 in which the 
electronic requests are generated automatically. 

53 . The method of claim 1 further comprising 

3 0 automatically processing the binary content of the image 

to verify the authenticity of the item. 
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54 . The method of claim 1 further comprising 
automatically processing the binary content to identify 
characters on the financial instrument. 

55. The method of claim 53 in which the 

5 processing includes using cryptography for determining 
authenticity. 

56. The method of claim 1 further comprising 
automatically processing the binary content to identify 
handwritten information. 



57. The method of claim 53 further comprising 
marking the financial instrument with an authenticity 
flag and automatically processing the binary content to 
identify the authenticity flag. 



58. The method of claim 1 further comprising 
15 automatically processing the binary content to determine 
if the financial instrument had been altered without 
authorization. 



59. A method comprising 

storing binary content of images of financial 
20 instruments in accordance with a predefined data 

structure and information uniquely identifying each of 
the images, 

encapsulating the binary content of each of the 
images in a delivery package that complies with a common 
25 protocol, and 

in response to a request for images having 
specified identifying information, sending packages 
containing the binary contents of the images in digital 
form. 
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60. The method of claim 1 in which the processing 
of the first electronic representation includes selecting 
only snippets of the binary content for inclusion in the 
digital delivery format. 



WO 97/22060 



PCTAJS96/20358 



1/9 



CLEARING HOUSE 



1 2 




PAYMENT ^ q 



FIGURE 1 



SUBSTITUTE SHEET (RULE 26) 



NSOOCID: <WO 9722060A1_IA> 



WO 97/22060 PCIYUS96/20358 




MSDOCID:<WO 9722060A1 IA> 



WO 97/22060 



PCT/US96/20358 



3/9 




FIGURE 3 



SUBSTITUTE SHEET (RULE 26) 



ISDOCID: <WO 9722060A1JA> 



WO 97/22060 



PCT/US96/20358 



4/9 



50 



SCANNER 



.6 4 



IMAGE CAPTURE SYSTEM 



CODELINE DATA 
PROCESSING SYSTEM 



EDI TRANSLATOR 



66 



74 



ILS 



62 



56 



ARCHIVE 



□ 

2ZS 



-5 8 



PRINTER | 



72 



r 



75 



OTHER BANKING 
APPLICATIONS 



BANK 



FIGURE 4 

SUBSTITUTE SHEET (RULE 26) 



si.snnnn <wn pT?onfinAi ia> 



WO 97/22060 



PCT/US96/20358 



5/9 

CHECK PRESENTMENT APPLICATION 



1 00 



CAPTURE IMAGES ' 




f 


STORE 


MAGES 



•1 02 



*1 04 



CREATE CODELINE DATA FILE 



-106 



CODELINE DATA FILE SENT TO ILS 



1 08 



ILS TRANSLATES TO X9.46 




f 


ILS DETERMINE 


IS RECIPIENT 



112 



TRANSMIT 



RECEIPT 



-1 14 
"1 16 



ILS DETERMINES NATURE OF DATA 



*1 1 8 



ILS TRANSLATES TO USABLE FORMAT 



—120 



INTERFACE FILE FOR PROCESSING 



"122 



PROCESS DATA 



"124 



FIGURE 5 

SBSn^ SHEET (RULE 26) 



>ISDOCID: <WO &722060A1 1A> 



WO 97/22060 



PCT/US96/20358 



6/9 

CHECK QUFRY APPLICATION -" 1 30 



cl 

1 32 



SINGLE ITEM 
REAL TIME QUERY 



BATCH QUERY 



QUERY REQUEST SENT TO ILS 



ILS TRANSLATES TO X9.46 



ILS DETERMINES RECIPIENT 

— r- 



*136 
v 1 38 
^140 



TRANSMIT 

T— 



RECEIPT 

— r~ 



"142 
-144 



ILS DETERMINES NATURE OF DATA 



ILS TRANSLATES TO USABLE FORMAT 



INTERFACE REQUES T WITH ARCHI VE 



"146 

"^1 48 
• 1 50 



SERVICE REQUEST 



RESPONSE SEN T TO ILS 



ILS TRANSLATES TO X9.46 

— — - z — — — 



ILS DETERMINES RECIPIENT 



■1 52 

'1 54 

^156 
58 



TRANSMIT 

T— 



RECEIPT 



60 
162 



ILS DETERMINES NATURE OF DATA 



ILS TRANSLATES TO USABLE FORMAT 



-164 
~M 66 



DISPLAY IMAGES 



134 



STORE DATA/ IMAGES 



0 



168 



FIGURE 6 

SUBSTITUTE SHEET (RULE 26) 



170 



ro.QrvY-.irv /uun omnwii ia-» 



WO 97/22060 PCT/US96/20358 



7/9 



LL 


. h- Q- ^ 


UJ , 


S < i^OhlUJH 


_ z 


u o 2 _ z o | 


Xode- 


lines 


jDuery 


Request 


Query 


"Result 



UJ 



-b CD o 

I ^ « 

g CD CL 



0) 

c 



o 

:= CD 

O c 



5>s W 

C CD 

CD 3 

o • 



^ CO oc 

5 2 2 

X < h- 

of 5 

UJ 



^5 

CD to 
3 <d 
O DC 



0) 






_co 




CO 




CD 


CD 
C 


c 






CO 
w 


6X 


ode 


Q 




o 


UJ 







CO CD 

CO 3 

CO 

J= co 
^ 

Q CD 



to 

CD 
3 

cr 

CD 

CC 











TO 


CD 




to 


3 




c 

CO 


o 


3 
CO 


k_ 


CO 


Re 


5 






UJ 


X 






.E CD y 
O - 



(0 



3 X CO 

° 5 



rn 






Codeline 
Interface 




Query 
Result 
Interface 


EDI X9.4< 

TO A KIC 

TRANo- 


Query 
Request 
Interface 



LLi 
DC 
3 
CD 

Li. 







CO 






O 








slat 


CD 


CD 


Q 


X 


odelin 


LU 


ran: 


uild 






00 


o 



co CD ^ 

CO ^ . LL 

~ 2 ^ 

- 3 § 

Q CD £ 



2 co 

CO TT 



CD 



LL 

CO CD 



-3° 

Q CD 
UJ 



to 

CD 
3 

cr 

(D 

CC 



LL h 0. 



LU 



< — 



O H I LU CC 



o=>hoo~zo 



SUBSTITUTE SHEET (RULE 26) 



JSDOCID: <WO 9722060A1_IA> 



WO 97/22060 



PCT/US96/20358 



8/9 



202 



QUERY REQUEST FUNCTIONAL GROUP 



204 



QUERY ID 



206 



ITEM VIEWS FUNCTIONAL GROUP 
208' 



ITEM DATA LOOP STRUCTURES 



^210 



r FINANCIAL DATA FUNCTIONAL GROUP 



1 2 



APPLICATION ACKNOWLEDGEMENT 
FUNCTIONAL GROUP 



21^0 



APPLICATION ACKNOWLEDGEMENT 



216 



FUNCTIONAL ACKNOWLEDGEMENT 
FUNCTIONAL GROUP 



218 



FUNCTIONAL ACKNOWLEDGEMENT 



220 



TRANSACTION 
SET REFERENCE 
ID 



ANSI X9.46 PROPOSED STANDARD 



7^ 



200 



FIGURE 8 

SUBSTITUTE SHEET (RULE 26) 



JSDOCID:<WO 9722060A1 IA> 



WO 97/22060 



PCT/US96/20358 



9/9 



J± 



01 



PAPER INSTRUMENT 



498 



BINARY CONTENT 504 



(APPROVED STRUCTURE) 
503 



510 



ENVELOPE 

(APPROVED STRUCTURE) 



X 



506 



f~ 500 



INSTRUMENT IMAGE 
INTERCHANGE 



9722060A1_IA> 



FIGURE 9 

SUBSTITUTE SHEET (RULE 26) 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US96/20358 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC(6) :G06F 17/00 157/00; G06T 1/00 
US CL : 395/245, 239, 235, 200.18, 885 
According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 
U.S. Please See Extra Sheet. 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
APS: SCAN?, DIGIT?, IMAGE, CHECK, CHEQUE, BANK, EDI, CODELINE 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category" 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant lo claim No. 



Y.P 



US 5,373,550 A (CAMPBELL ET AL) 13 December 1994 
(13/12/94), see entire document especially, Figure 1 & 2, 
abstract, column 3, line 17 to column 4, line 58. 

US 5,444.794 A (UHLAND. SR.) 22 August 1995 
(22/08/95), see entire document, especially column 5, line 
58 to column 6, line 56. 

US 4,754,428 A (SCHULTZ ET AL) 28 June 1988 
(28/06/88). Fig. 1. oclumn 2. line 59 to column 3, line 53. 

US 5,528,705 A (REASONER, JR. ET AL) 18 June 1996 
(18/06/96), see entire document, especially Fig. 1A, Column 
1, lines 9-64. 



1-60 



11, 21, 27, 40 



6, 20, 35, 47 



11, 13, 21, 27, 
29, 33, 36, 40. 
42, 45, 48 



[ x| Further documents are listed in the continuation of Box C. | | See patent family annex. 



•A* 

-E* 
*L" 

•O' 

•r 



Special calejona of cacti document!: 

doaancntdcJauni the general stale of the an which ■ not considered 
to be put of particular relevance 



•X" 



document which may throw doubt* on priority cuum(i) or wfaicb it 
chad k> mtahliari tbt publication date of toother ciuukn or other 
special reason (ai specified) 

document nlcfrmf lo an oral disclosure, use, cj»ibttt»oo or otber 



dongnmt published prior to the apternali nal fUmf dale bat fascr than 

the priority date churned 



•A' 



later document published after the micrnauoual fiLof dale or priority 
date and aot m cooflsci with the applies boo but c*od to loricrsuuid the 
principle or theory laaderiying the invention 

document of particular relevance; the claimed mvcniioa 
considered novel or cannot be considered to involve an 
when the document is takea alone 

document of particular relevance; the claimed arvenuoo 
considered to involve an bventive step when the 
oooabmcd with one or more other such 

the art 



t family 



Date of the actual completion of the international search 
14 APRIL 1997 



Date of mailing of the international search report 



0 1 MAY 1997 



Name and mailing address of the ISA/US 
Commissioner of Paienu and Trademarks 
Box PCT 

Wajbiagton, D.C. 20231 
Facsimile No. (703) 305-3230 




offic, 

Telephone No . (703) 305-971 1 



Form PCT/1SA/210 (second ihcd)(July 1992V* 



NRnnntn- <-wn QTPorwyti \&-> 



INTERNATIONAL SEARCH REPORT 



C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 



international application No. 
PCT/US96/20358 



Category" 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



Y, P 



Y,P 



FURASH & Company, Banking Role in Tomorrow's Payments 
System - Volume II - Payments Systems Overview, The Banker's 
Roundtable, June 1994 (06/94), see entire document, especially 
Check Imaging page 17-19. 

US 5,566,322 A (ADAIR ET AL) 15 October 1996 (15/10/96), 
abstract, column 1, lines 30-37, column 3, lines 10-63. 

US 5,432,506 A (CHAPMAN) 1 1 June 1995 (1 1/06/95), 
abstract, Fig. 1 & 2, column 1, line 54 to colomn 2, line 44. 

US 5,544,255 A (SMITHIES ET AL) 06 August 1996 
(06/08/96), abstract, Fig. 1, column 3, lines 36 to column 7, line 
4. 



37, 44 



49, 51 



53, 54, 55, 57, 
58 

56 



Form PCT/1SA/210 (continuation of ucond shect)(July 1992)» 

4SDOCID: <WO 972206OA1JA> 



INTERNATIONAL SEARCH REPORT 



International Application No. 
PCT/US96/20358 



B. FIELDS SEARCHED 
Minimum documentation searched 
Classification System: U.S. 

395/245, 239. 235, 526, 527. 200.17, 200.18, 885; 235/379, 380; 380/23, 24. 25. 54; 340/825.3 , 825.33 . 825.35; 
382/139, 140; 902/40 



Form PCT/1S A/210 (extra thectXJuly 1992)* 



MSDOCID: <WO 9722060A1 IA> 



